IronPython URLs

Harry Pierson, IronPython program manager for Microsoft, has written a series of posts on using a new feature in IronPython 2.6 to assist with debugging when embedding IronPython in .NET applications. The focus is not just on embedding for scripting, but actually using IronPython for polyglot programming - writing hybrid applications using both IronPython and C#. Lightweight Debugging for Hybrid C#/IronPython Apps  Seriously, let me introduce you to the worlds simplest Twitter application: GetThings. The app downloads a list of my tweets via the Twitter API and displays them in a list box. The UI is written in C# while the tweet download code is written in Python. Clearly, this is a pretty brain dead app – but the point isn’t to build a great Twitter app but rather to show how to use the settrace API from C#. I’ve stuck the code up on GitHub. If you want to see the basic app in action sans debugging, start with the initial checkin. As you can see here, basic C# / IronPython int...

For IronPython users interested in tool support the big new feature in IronPython 2.6 is the support for Python stack frames and all that comes along with it. Not a small part of this is that pdb , the standard library Python debugger, will work with IronPython - yay! Harry Pierson (IronPython program manager for Microsoft) has a new blog entry detailing the new assembly that will come with IronPython 2.6 (but will actually be part of the Dynamic Language Runtime) to support this: Microsoft.Scripting.Debugging If you’ve compiled IronPython from source recently, you may have noticed a new DLL: Microsoft.Scripting.Debugging. This DLL contains a lightweight, non-blocking debugger for DLR based languages that is going to enable both new scenarios as well as better compatibility with CPython. Needless to say, we’re very excited about it. ... Of course, we hide all this DLR Debugger goo from you in IronPython. Python already has a mechanism for doing traceback debugging – sys.settrace . Our ...

Another selection of articles on IronPython from the last few weeks. Scripting: Reliably Finding my 32bit EXEs on a 32bit & 64bit OS or Where is IronPython? Saveen Reedy has a problem finding IronPython. More to the point he has an issue reliably finding the installed location when using both 32bit and 64bit versions of Windows (which have different standard install locations). Iron Python: How to talk to the .NET Framework A short blog entry demonstrating how IronPython integrates with the .NET framework by creating a simple GUI with Windows Forms and the interactive interpreter. The steps are virtually the same as I use when demoing IronPython to a .NET crowd. Creating Python Modules from CSharp This one is a bit meta, but still useful. It's a recipe I put on the IronPython cookbook and shows a 'slightly-different-from-the-usual' way to integrate C# with IronPython. It shows how you can use C# to programmatically create Python modules for use from IronPython. Back to ...

This post features three blog entries on tools being developed for or using IronPython. Profiler Part II: Poor Man's Code Coverage Curt Hagenlocher (core IronPython developer blogging as IronCurt) had been working on a profiler for IronPython ; one of the standard programming tools that up until now has been difficult or unavailable for IronPython. This is his second post on the profiler, which is being built into IronPython itself. He explains how it works, how to use it, and how it can also be used as a code coverage tool. Writing an IronPython Debugger: Breakpoint Management Harry Pierson (IronPython PM and blogging as DevHawk) has been working on an IronPython debugger . In this blog entry he explains how he has extended the breakpoint handling of his debugger beyond the simple breakpoint setting that he implemented very early on: "Setting a breakpoint was the second feature I implemented in ipydbg. While setting a breakpoint on the first line of the Python file being run ...

Harry Pierson (Microsoft IronPython PM) has been experimenting with writing an IronPython debugger ( ipydbg ) on top of the .NET MDbg APIs. When we last left him , he had implemented Just My Code (JMC) support allowing you to step into IronPython code. Since then he has made a lot of progress including a colourful REPL (interactive console) and solving some difficult problems around getting to real values behind boxed IronPython variables (needed for showing local variables). He has blogged extensively on what he has been up to (more recent posts last): Showing Source Code Colorful Console IronPython ConsoleColorMgr (the colorful console code pulled out into a separate IronPython module) A Little Hack...err...Cleanup Getting Local Variables Displaying Values Command Routing Getting Arguments REPL Console A lot of functionality is now present. In the command routing entry Harry outlines the seven commands supported by the debugger so far: Continue, Quit, Show Stack Trace, Show Locals, ...

One of the things that programmers in static languages complain about working with dynamic languages is the lack of tools. Many of them are unaware of the tools that are available for languages like Python: A plethora of Python IDEs and editors exist; with good support for syntax highlighting, autocomplete (intellisense), call-tips and all the features you expect from an IDE. Good ones include: Wingware Wing IDE (which includes a very powerful debugger) Activestate Komodo IDE Eclipse with PyDev Stani's Python Editor (free with integrated debugger) Netbeans and Python Many more including the old warhorses Emacs and Vim; beloved as lightweight companions to lightweight languages (and easy to integrate with the other tools listed here) Code coverage tools: coverage.py The debugger included with Python: pdb The profiling tools included with Python: profile library Refactoring tools: rope , Bicycle Repair Man Code quality tools: PyFlakes (fast), pylint (comprehensive), pychecker (i...

Ryan Brady has posted a great blog entry with step-by-step instructions on how to debug IronPython code with the Visual Studio debugger (unfortunately it requires Visual Studio Professional and so doesn't work with Visual Studio Express - although it is possible that you could get round it by building IronPython from source as part of your solution): Debugging IronPython in Visual Studio The steps he lists are (although if you go directly to his entry it has more detailed instructions along with pretty pictures): Create a Python file to debug. From Visual Studio, open the IronPython executable (ipy.exe). If it doesn’t do so for you, add the ipy.exe as an existing project. From the Solution Explorer, right-click on Properties and set the Command Arguments property. Use “-D” to tell ipy.exe to create debugging output and add the full path to the script you made before. Click Ok. Open the script you created earlier in Visual Studio and place breakpoints as desired. Run the script in ...

Crack.NET is a runtime debugging and scripting tool that gives you access to the internals of any .NET desktop application running on your computer. Crack.NET allows you to walk the managed heap of another .NET application, inspect all kinds of values on objects, and even manipulate those objects via IronPython scripts. Crack .NET Homepage Download from Codeplex Article on Crack .NET (word document) Once you find an object or type that you're interested in, you can manipulate it, and others, by writing and executing an IronPython script. Crack.NET was built against version 1.1.2 of IronPython.DLL and IronMath.DLL.

IronPython is a Python compiler. This means that it compiles Python sourcecode into IL (Intermediate Language), the bytecode of the Common Language Runtime. (Although that bytecode is interpreted, like the CPython compiled bytecode, .NET languages are typically called compiled languages because the IL can be compiled to native code by the .NET JIT compiler.) This IL remains heavily dependent on the main IronPython assemblies (and Dynamic Language Runtime assemblies in the case of IronPython 2) in order to implement the highly dynamic semantics of Python - but it is still compiled IL that is running. This is done using the .NET ' Reflection.Emit ' API to generate the IL (and the lack of this API in .NET Compact Framework is why we can't run IronPython code on the XBox 360 or Windows Mobile devices). It also means that you can use standard .NET debugging tools like ' windbg.exe ' to introspect and debug your IronPython code in memory. In his latest blog entry Curt Hag...

Harry Pierson has written up how to use Visual Studio to debug IronPython code: Debugging IronPython Code with Visual Studio

Kamil Dworakowski has done an update to his post on the " Static Subject to Observer Mapping Anti-Pattern " that was causing a memory leak in Resolver One . This post details the tools and techniques he used to trace the memory leak in an IronPython application. Debugging Memory Problems in IronPython

Nauman Leghari blogged recently on IronPython and Cecil : Fun with IronPython & Cecil Part I Fun with IronPython & Cecil Part II "Cecil is a library written by Jb Evain to generate and inspect programs and libraries in the ECMA CIL format. It has full support for generics, and support some debugging symbol format. In simple English, with Cecil, you can load existing managed assemblies, browse all the contained types, modify them on the fly and save back to the disk the modified assembly." He has followed thes up with: Fun with IronPython & GLEE GLEE is a .NET tool for graph layout and viewing. It has been developed in Microsoft Research. and then: Method Tree Visualizer :: Fun with IronPython, Cecil and Netron Graph - Part III As I said in the last post, the output from Microsoft GLEE looked but not ideal and as the method tree gets bigger with more relationships, the diagram gets out of control. Disappointed with that, my further search takes me to the Netron P...

Michael Foord posts about an IronPython traceback bug discovered during profiling an application. http://www.voidspace.org.uk/python/weblog/arch_d7_2006_12_30.shtml#e601

Martin Schray finds that dynamic languages are benefical after all. http://mschray.spaces.live.com/Blog/cns!9B3D7B460D023307!388.entry

I post about a solution I use to do trace style debugging with IronPython and web/service applications. http://hex-dump.blogspot.com/2006/11/ironpython-and-trace-style-debugging.html

A short screencast to show how you can use IronPython and Snoop (WPF debugging tool) together to explore the Windows Presentation Foundation (WPF) http://mattgriffith.net/PermaLink.aspx?guid=a1cb7215-2719-4c38-8ce3-ba7408aa69aa