Posts

Showing posts with the label team

IronPython at TechEd

TechEd 2010 has just finished, one of Microsoft's biggest developer conferences. Lisa Feigenbaum, who is program manager for the Visual Studio Languages Community, has posted a blog entry with links to all the  Visual Studio Language & IDE Resources from TechEd North America 2010 (C#, VB, F#, IronPython, IronRuby). Our own inestimable Dino Viehland, the IronPython workhorse and genius, was there and gave two presentations on IronPython: USING DYNAMIC LANGUAGES TO BUILD SCRIPTABLE APPLICATIONS Abstract: The Dynamic Language Runtime (DLR) brings the power of dynamic languages to Microsoft .NET. It provides the plumbing for IronPython and IronRuby, a shared language hosting API, and also enables interoperability with static languages like C# and Visual Basic. Come hear how you can leverage these technologies in your own applications, and learn why dynamic languages deserve a spot in your toolbox! IRONPYTHON TOOLS  Abstract: IronPython Tools for Visual Studio is a...

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

Another collection of IronPython and DLR related articles from recent weeks. Jim Hugunin: Modelling the World Jim Hugunin is a bit of a Python veteran. As well as being the creator of two implementations of Python (Jython and IronPython), he also started the Numpy project (back when it was called Numeric). Not long ago he was swallowed by Microsoft, who also took on the development of IronPython and turning it into the Dynamic Language Runtime. In this video interview Jim explains not only how he got involved in Python, but also what he has been up to recently. IronPython Tools for Visual Studio with Expression Blend One of the ways that .NET helps you separate your visual design from your application logic is through XAML; an XML based declarative language that can be used with both Windows Presentation Foundation (WPF) and Silverlight. Naturally there are design tools that will generate XAML. Visual Studio is one of them, but the best one is Expression Blend. XAML has features...

A Good Mix 32: Alpha Encoding Files, Embedding IronPython in Russian, IronSharePoint, IronRuby, World's Worst Paint Program

More IronPython and DLR related projects, articles and news from around the web. Alpha-encoding file versions  Steve Gilham shows how to generated encoded version strings for installers using IronPython: When building installers the UpgradeVersion must have a unique property value that is an installer public property (upper-case alpha). So, what better way of adding uniqueness than making it have the form "product name + product version" with the version suitably encoded... So, a script for turning a file version (4 x 16bit ints) encoded as a System.Version into a short alpha string, assuming that Major and Minor will be small, and that common approaches are to step Build, to use a stepped Build plus date-stamped Revision, or a timestamp Build and Revision. C# + IronPython: вызов методов An article on IronPython, and in particular using IronPython from C#, in Russian. IronSharePoint Source Code Available   A while ago Christian Glessner announced the start of the I...

IronPython at PyCon 2010

PyCon 2010 , the annual international Python conference is coming soon (February 17th 2010 in Atlanta US). The schedule of talks is now up, and as usual there are several IronPython related talks . 67. IronPython Tooling  By Dino Veihland, core IronPython developer: One of the most popular requests for the IronPython team is tooling support. During this talk I’ll show you some of the existing tools available to help create IronPython applications. I’ll also look at the latest IronPython features which can help you debug, profile and improve your applications. I’ll also compare and contrast these with the solutions available for CPython that you may already be familiar with. 71. Python in the Browser By Jimmy Schementi (Microsoft program manager for IronPython / IronRuby Silverlight integration): You write your server code in Python because you want to. You write your browser code in JavaScript because you have to. But with IronPython and Silverlight, you can write your brows...

The Dynamic Languages Team

A blog entry from Lisa Feigenbaum (the Microsoft Visual Studio Languages Community Program Manager) introduces us to all the members of the IronPython and IronRuby development teams and the MVPs (community members). Connecting with IronPython & IronRuby Team Members IronRuby: website , mailing list IronPython website , mailing list In the blog post you can find details of all the team members, including links to their blogs and twitter accounts. Team members: Jim Deville (IronRuby) Jimmy Schementi (program manager for dynamic languages Silverlight integration) Harry Pierson (IronPython program manager - but not for much longer) Dave Fugate (IronPython testing and release infrastructure guy) Dino Veihland (IronPython) Tomas Matousek (IronRuby I *think*) Shri Borde (the man in charge) David Dicatio (IronPython) Missing from this list is John Lam (IronRuby program manager) and Curt Hagenlocher who was an IronPython developer but may now be working on a secret projec...

IronPython 2.6 Release Candidate 2 and news from DevHawk land

A new release candidate for IronPython 2.6 has just been released. This is the third release in under a week for the IronPython team, following on from the releases of IronPython 2.0.3 and and IronPython 2.6 for .NET 4.0 Beta 2 . IronPython 2.6 is (or will be) a big release. The major feature is compatibility with Python 2.6, but there are a whole host of others features as well: The __clrtype__ metaclass for data binding and .NET attribute support Implementation of the ctypes module Support for Python stack frames and sys.settrace , which means the pdb debugger works Better performance through adaptive compilation Faster startup The new release: IronPython 2.6 Release Candidate 2 Performance Comparison of IronPython 2.6 RC2 and Python 2.6 We’re pleased to announce the release of IronPython 2.6 Release Candidate 2.  Since the public availability of Release Candidate 1, we’ve addressed the following: The “ json ” CPython package has been included with our MSI insta...

Catching up with Devhawk: Using Python libraries from C#, the HawkCodeBox and a world tour

Devhawk, otherwise known as Harry Pierson, is the program manager for IronPython on the Microsoft dynamic languages team. He is a prolific, even more than me, has a whole bunch of interesting IronPython related posts that I've fallen behind on. The first set of posts is about building a hybrid Python / C# application, specifically using the awesome Pygments syntax highlighting library from a .NET application. Pygments for Windows Live Writer v1.0.2 Harry has been working on a syntax highlighting plugin for the Windows Live Writer desktop blogging tool. He's using Pygments via IronPython 2.6 Beta 2 to do the highlighting, and barring some problems with the import magic Pygments does (known by the IronPython team as “Harry’s Pygments Import Bug”) it works fine with IronPython. Building a Hybrid C# / IronPython App without Dynamic Type C# 4.0 introduces a new feature, the dynamic type, that will make embedding and interacting with dynamic languages from C# much easier. If you w...

IronPython 2.6 Beta 2 Released (performance, ctypes, frames and more)

Hot on the heels of IronPython 2.0.2 is a new release - the second and hopefully final beta of IronPython 2.6. The big new features in IronPython 2.6 are: Python 2.6 compatibility The __clrtype__ metaclass for data binding and attribute support Implementation of the ctypes module Support for Python stack frames and sys.settrace , which means the pdb debugger works Better performance through adaptive compilation Faster startup In the announcement of the release Dave Fugate had this to say about the timetable for IronPython 2.6: At this point we are essentially feature complete from a CPython 2.6 perspective, and look forward to making available IronPython 2.6 Release Candidate 1 within the next couple of months. As such, we’d very much like everyone to try out this release and report back any major problems you may encounter so we can fix them in time for the first release candidate. Any bugs that you find can be reported via Codeplex . IronPython 2.6 Beta 2 Download and Release Not...

Dave Fugate on IronPython Details

Dave Fugate is an IronPython tester, and often responsible for releases. He's posted a few blog entries on recent changes in IronPython 2.6 (alpha 1 was just released ) and building IronPython from source for Silverlight. CPython 2.6 Standard Library and IronPython 2.6 In Python 2.6 the standard library collections module uses sys._getframe , which doesn't work for frame depths greater than 0 in the current IronPython. A whole host of other standard library modules depend on collections, meaning that they are all currently broken for IronPython 2.6! Dave explains how to modify collections.py to get round the problem. The good news is that in the final version of IronPython 2.6 getframe will be available from a command line switch (there is a performance hit for having it enabled). Without the switch it will be undefined (and collections.py already has a workaround for this), so that in either case you will be able to use an unmodified standard library. Building IronPython / Ir...

Welcome David DiCato to the IronPython Team

Shri Borde (IronPython/IronRuby dev lead) just posted this to the IornPython mailing list: Please welcome David DiCato to the IronPython team. He has his first shelveset in the Snap queue ( queue.__init__ calls clear) already. You should hopefully hear more from him in the mailing list. Here is his intro in his own words. " Hi everyone, I’m David DiCato, the new Dev on the IronPython team. I grew up in Surf City (i.e. Huntington Beach, CA) and moved just 50 miles north to go to school in Pasadena. At Caltech, I earned my BS in Computer Science, applied to Microsoft after a short break, and the rest is history. Although I have never touched a surf board, I like to dabble in snowboarding, as well as piano, guitar and biking, although I’m good at none of these things. I’m also a big fan of music, incl. classic rock, punk and electronic, and film, incl. Kubrick, Hitchcock and Scorsese. " Welcome to David. He doesn't seem to have a blog yet, but he has been warned that as me...

The Microsoft Dynamic Languages Team Blogroll

The dynamic languages team at Microsoft are relatively small, but have an extremely high proportion of bloggers! (The obvious conclusion is that dynamic language enthusiasts tend to be better communicators...) Oleg Tkachenko lists them on his blog: The Microsoft Dynamic Languages Team Blogroll For the record, they are: John Lam – IronRuby PM Harry Pierson – IronPython PM Jimmy Schementi – PM for Silverlight integration Shri Borde – dev lead for the team Dave Remy – PM lead fro the team Oleg Tkachenko – Visual Studio integration Dave Fugate – IronPython tester Curt Hagenlocher - IronPython/IronRuby dev Jim Hugunin – architect for the team, DLR and Visual Studio languages Tomas Matousek – IronRuby dev Srivatsn Narayanan – IronPython/IronRuby tester Jim Deville – IronRuby tester Dino Viehland – IronPython dev We're trying to keep track of them on the People in IronPython page of the IronPython Cookbook.

REMLOG and the Dynamic Languages Braintrust

Dave Remy is the uber-commander-in-chief of the dynamic languages at Microsoft, and he blogs. If you've ever wondered what the dynamic language team members look like, Dave has some photos of them from a lunch meeting with the 'brain-trust': Lunch with a Dynamic Languages Braintrust He also got together with Mike Vincent, who is " on the Board of Directors of INETA (International .NET Association) which works to coordinate a huge community of .NET user groups ". INETA is in touch with a large community of .NET developers: " It appears INETA has great momentum, with greater than 250 active user groups and over 100,000 active developers in North America, and a reach of approximately 1.2 million developers world-wide. " Meeting Mike Vincent "One question we asked was how important Mike saw Visual Studio Integration for the Iron languages. We get feedback at times that it is more important to have a lightweight, quick to bring up, quick to close down,...

RemLog: Back to Microsoft

Dave Remy blogs about his return to Microsoft - as lead program manager for the GO team (which includes languages like F# and IronPython). Back to Microsoft " I had an informal meeting with Drew and, what do you know, the Visual Studio Languages Unit has a team called the “Growth Opportunities” (GO) team that is responsible for IronRuby, IronPython and emerging languages. They needed a Lead Program Manager. I took the position and now I am working on a truly great team with folks like John Lam (the face of IronRuby), Harry Pierson (DevHawk blogger, IronPython PM), Jimmy Schmenti (Dynamic languages PM, wrote the Silverline plugin), Tomas Matousek (most awesome IronRuby developer), Dino Viehland (most awesome IronPython developer), Jim Deville (IronRuby QA), Curt Hagenlocher (both IronPython and IronRuby developer), Jim Hugunin (Dynamic Language Runtime and IronPython Architect), Bill Chiles (Dynamic Language Runtime Program Manager) and many, many more. " (Via DevHawk...

Dave's Ramblings: Dave Fugate on Testing IronPython Performance

Dave Fugate is a tester on the IronPython team. The IronPython team has recently done some great work on IronPython 2 performance improvements and Dave has started blogging on how they measure IronPython performance. His initial blog entry introduces himself and what he does (plus IronPython related topics he intends to blog about): Jumping back on the blogging bandwagon He has a two part blog entry on how they measure performance (the hardware infrastructure) and the results over time comparing 32bit to 64bit OSes. Every checkin triggers a benchmark run that takes over six hours (running a combination of PyBench, PyStone and custom microbenchmarks) on custom OS install. Measuring IronPython Performance Part 1 The second part compares performance (both PyStone and PyBench) for two identical machines - one running 32bit Vista and the other running 64bit Vista. Interestingly performance is worse for x64 architecture than it is for x86. Measuring IronPython Performance Part 2

New IronPython Wiki Pages: IronPython People, Knol, SSIS and MP3 tags

There are five new wiki pages, across three different wikis (well - perhaps two wikis and a pseudo wiki) about IronPython. There are three new pages on the IronPython Cookbook . People in IronPython A page on the different people in IronPython. It includes notes on the different teams and Microsoft and their roles, plus the Resolver Systems guys and a few other folk who've made contributions to the IronPython community. If there is someone missing who you think ought to be there, please add them. Programmatic Control of SSIS This is " a collection of utilities for programmatically controlling SQL 2005 SQL Server Integration Services (SSIS) packages with IronPython ". Read ID3 tags from an MP3 " This simple routine uses the Windows Shell to get MP3 file information from the tags. Due to the differences between Vista and XP different magic numbers are required to get the tags. " IronPython on Google Knol Knol is google's project for 'user created knowledg...

IronPython Post 2.0 Roadmap Clarifications

A couple of weeks ago, Harry Pierson (IronPython PM) posted a roadmap outlining Microsoft's plans for supporting Python 2.6 and 3.0 - once IronPython 2.0 (which targets Python 2.5) is out of beta. He also discussed the plans for future IronPython and Visual Studio integration (something that Curt Hagenlocher was originally hired for - but he couldn't resist the lure of working on IronRuby as well and another new hire - Oleg Tkachenko will be focussing on the VS integration for both IronPython and IronRuby). As the core Python developers will be maintaining Python 2.X and 3.X in tandem for a while, whilst the community transitions over to Python 3, I asked if IronPython would do the same - or whether IronPython 2 would be left behind once work on IronPython 3 begins. Another commentor, Francois, was keen to know whether the Visual Studio integration would require users to purchase Visual Studio - or whether they would be able to use the Express version or the VSx Shell as is...

OLE Automation support ON in IronPython 2.0 Beta 4

IronPython 2.0 beta 4 isn't out of the door yet, but already the team are blogging about some of the new features. Shri Borde has a new blog entry about OLE Automation with IronPython, without having to rely on interop assemblies. This makes for easier automation of Excel, Word and any other COM enabled Windows applications. In previous versions of IronPython trying to doing this without the Primary Interop Assemblies available would try to generate them on the fly (which could take several minutes). But with IronPython 2.0 BEta 4 it should work fine through IDispatch . Shri provides some details of how it works in practise, how it works under the hood, and some of the known issues (including how to turn it off if it causes any problems!). OLE Automation support ON in IronPython 2.0 Beta 4

Curt Hagenlocher: This... is... Dynamic!... and StackOverflowException in IronPython

Curt Hagenlocher, the newest (well... as far as I know) member of the IronPython team has started blogging as Iron Curt . He has two blog entries already. The first explores stack overflow in IronPython (which is a catchable error in Python), and how it maps to the underlying Common Language Runtime (where it is generally an unrecoverable error). By default IronPython doesn't catch stack overflows ( sys.recursionlimit is set to MaxInt ), because there is a performance overhead in monitoring the frame depth to catch the exception. Curt explores the issues around this for IronPython. StackOverflowException and IronPython In the second entry he takes this further by looking at CLR exception filters (through the eyes of some VB.NET) to show why they can't be used for IronPython exception handling. This... is... Dynamic! This is part of what it means to be dynamic. Take the power and use it wisely.

CLS Compilation of IronPython

In IronPython (and other Dynamic Language Runtime languages) Python classes are not static .NET types. There are various reasons for this. .NET classes can't be garbage collected (assemblies can't be unloaded - unless you load them in another AppDomain and unload the whole AppDomain). Additionally dynamic languages typically allow you to add and remove members at runtime and in Python you can even change the base classes at runtime. For instances of Python classes we can also change the class at runtime, not usually recommended but possible... This means that normally a Python class can't be a static .NET type, instead Python classes are .NET objects (instances of their metaclass - for new style classes without a custom metaclass that means ' PythonType '). This isn't without problems - in order to apply .NET attributes you basically need a sttic type. This leaves a hole in the interoperation between Common Language Runtime features and dynamic languages, and m...

Snippets from Devhawk

Harry Pierson (Devhawk and Microsoft IronPython PM) regularly blogs interesting snippets of news. His "Morning Coffee 166" edition has several IronPython and Dynamic Languages related pieces of news. There is a new Dynamic Language Runtime Hosting spec available ( doc , pdf ). If you're embedding IronPython into languages  like C#, VB.NET or even F# or Powershell, this is an invaluable and surprisingly readable document (well - if you like reading heavily technical documents). As IronPython PM Harry has a new boss - Dave Remy. Dave doesn't blog, but Jim Deville, a new member of the Dynamic Languages team working mainly on IronRuby does . There is also yet another  new member of the Dynamic Languages team. Oleg Tkachenko, who also blogs . IronRuby has a new wiki and homepage . The front page has a bright and shiny picture of Matz (Ruby BDFL) wearing a Python T-Shirt! Devhawk: Morning Coffee 166