- don't forget to click on  on bottom right of player

 

Recently, I have been focusing on updating my web-based DLR IDE which is one of five components that make up a larger project called Global System Builder.

 

In a previous post, I mentioned that I would like to develop a DLR IDE in Silverlight, but I am still having a time figuring out Silverlight, especially trying to debug web-based Silverlight applications.

 

In the meantime, I continue to extend this JavaScript code editor called “EditArea” by Christophe Dolivet.  What an excellent job he has done!  Features include:

 

·        Live syntax highlighting for several languages and the ones that I am interested with the DLR which is Python, Ruby and Managed JScript.

·        Multiple-document support with tabs

·        AJAX load and save functions

·        Line numerations

·        Search and replace (with regexp)

·        unlimited undo and redo

·        Auto-indenting – great Python support!

·        Font resizing

·        Internationalization

·        Toolbar customization – add your own commands via plug-ins

·        Full screen capability

·        Create new syntax or language files

·        Multi-browser support

·        Multiple instances on the web page (if required)

 

Really quite amazing and it has been working excellent for me.  Great job Christophe!

 

I can load and save files to the disk in a project hierarchy.  I can create new files and then save to disk.  If you open a file and start editing it, you will notice that an asterisk is added to the filename tab to tell you that the file has changed. 

 

It looks like there are two items left for me to implement, each one with their own set of difficulties:

1. Intellisense
2. Debugging

I prefer to GUE (Go Ugly Early) to try and mitigate risks, so it is going to be Adventures in Debugging.  But before I do, Intellisense will be tricky as well since Intellisense has quite an array of features.  My goal is to only implement “List Members” and “Parameter Info.”

 

Back to debugging and without getting too philosophical, I can’t image any “real” IDE that does not have debugging support, especially if you are working on any size of code base.  I view it as the same as driving at night with no headlights – you are bound to hit something hard sooner than later. So what choices do I have for debugging with the DLR and my custom IDE?  As far as I can tell, there appears to be one choice and that is MDbg.

 

You can download MDbg and compile it.  You will need to add this trick (see answer at bottom) to get the help to work on the command line.

 

Mike Stall is the MDbg guru and he has a great MDbg link fest to get you started.  I also really liked Jan Stranik’s Introduction to the Managed CLR Debugger as it shows how you can easily write an extension using the debugger API.  You can also download the videos.

 

So, how to start?  I started off by running MDbg and then issue the command line “load gui” to load a Windows GUI extension to make it easier to use then the command line.  This extension provides an excellent example on showing how you can get a debug window to step through code, show locals, etc.  Here is the code that I want to debug in my editor:

 

 

Dead simple, but a place to start. On the web server, I have a C# Windows Forms application that hosts an IronPython 1.1.1 engine in it.  I also have IP 2 with the DLR prototyped, but just trying it out on IP 1 for now. The application hosting the IP engine is called GSBService1.exe, compiled with debug symbols.  I can run MDbg and launch the app in the debugger:

 

 

The debugger attaches to the running process and breaks into the code at the main entry point:

 

 

You can type help to get a list of commands available that allows you to do all sorts of things such as setting/clearing breakpoints, stepping in and out of code, etc.  In addition, from the tools menu, you can open other windows such as viewing the Callstack, Locals, Modules, Threads and QuickWatch.

 

One of the commands is “x” which lists the loaded modules.  You can see which modules are loaded in my application.  You can also specify a particular module and display specific functions by pattern matching.  Here is the help usage:

 

 

Note that I am looking for the function in the module gsbservice1 that executes my .py file – I know the function contains “ParseInteractive”, so I use the x command again to find it using the pattern matching.  Then I can specify a break point by the command b ~1.  I then issue the go command (g) and now I am running and all set to debug at my breakpoint.

 

I go back to my web-based code editor and hit the command Start Debugging and immediately drop into the debugger at my specified breakpoint:

 

 

Here I am stopped at my breakpoint and I am starting to step over (command o) the code.  In fact, I stepped over the code until the Python code was compiled by the IronPython engine.  So how come I could not step into the IronPython code?

 

 

If you look closely, you will see that I used the x command again to see what modules are loaded and lo and behold a module called, “debuggableSnippets2.dll” What’s in there? Using x command on the module, you can see my compiled .py code with the class name and methods that correspond to the source that I entered in the code editor.  Searching on debuggableSnippets points to this source:

 

// IronPython has two units of compilation:

    // 1. Snippets - These are small pieces of code compiled for these cases:

    //    a. Interactive console expressions and statements

    //    b. exec statement, eval() built-in function

    //    c. Types generated by NewTypeMaker for instances of Python types

    //    d. others ...

    //    All snippets are created in the snippetAssembly. These are created     using GenerateSnippet.

    // 2. Modules - Modules are compiled in one shot when they are imported.

    //    Every Python module is generated into its own assembly. These are created using GenerateModule.

    //

    // OutputGenerator manages both units of compilation.

 

Makes sense.  It’s nice that I can step through my C# code that hosts the IP engine, but what I am really interested in is stepping through the Python code.

 

I see that others have been able to do it and others here as well.  But not sure exactly “how” they are doing it.  Maybe someone will enlighten me.

 

Note in the forum that Mike Stall indicates that there may be some issues with MDbg and that perhaps an updated version is forthcoming.  That was over 6 months ago.  I really hope the MSFT DLR/IronPython teams keep tool support in mind and provide an updated version of MDgb.  Maybe Michael Foord, Douglas Blank, Ben Hall, and Stefan Dobrev can help lobby Harry Pierson to keep MDbg current and able to work with the DLR. 

 

We are all building DLR IDE’s of various sorts (IDE Developer and DLR IDE on Codeplex) and MDbg seems the most likely candidate as a debugger – for those that want debugger support.  Also, I suspect that this is a precursor for people wanting to create their own languages on top of the DLR, so you would think debugging tool support would be important.

 

In the meantime, if I can only figure our how to get MDgb to debug IronPython code…  And I may have to wait for Beta 4 to try it out on IronPython 2.0.

Years ago I lived in a Smalltalk world and never knew how good I had it.  As Larry O’Brien says, “Smalltalk has enough proponents so you're probably at least aware that it's browser and persistent workspace are life-altering (if you aren't, check out James Robertson's series of screencasts).

 

Unfortunately, in the Great White North, not too many Smalltalk jobs were available and in fact it really boiled down to programming Windows or Unix.  And somehow I found myself in the Windows world using Visual Studio and Visual Basic.  In some respects, VB was almost Smalltalk like – I loved the interpreter of stepping through code, finding a mistake, fixing it on the spot, setting next statement to run a few lines back and stepping through and keep on going.  I found myself enjoying the rhythm of it and how productive I was.  That was the thrill for me.

 

Then came C# which is a statically typed language, but what really got me was the rote of write code, compile it, fix compile errors, then compile it again, fix runtime errors, compile it again, step through, note the error, stop debugging, edit code, compile it again, etc.  As you can imagine from the VB world, the most common error I got was, “are you missing a cast?”  Also, my productivity just was nowhere near as fast.

 

A year or so ago, I came across IronPython.  What I loved immediately was the interactive console that interpreted code on the fly.  I type in my line of code and execute it with immediate results.  For me, I work best like this.  It allows me to experiment with CLR types and once I have it figured, I can then cut n paste into a code file and build up my application.

 

What is really exciting to me is that the DLR is intended to support a variety of dynamic languages, such as IronRuby by John Lam and others… yes, even Smalltalk.  Way to go Peter Fisk!