The CLR team recently had a compiler dev Lab on campus in building 20, with a strong focus on dynamic languages.

I gave a talk on the 3rd day about the debugging services in the .NET platform. It was mainly a buffet-style sampling of what the .NET debugging services offer. Targeting your language .NET gives you a great set of debugging services that free you up to worry about more interesting problems.

The contents were roughly:

1. A brief overview of the debugging services ("what is ICorDebug?")
2. Raise awareness of MDbg as a toy to prototype new debugging ideas with.
3. Demo how you can debugging IL (round-tripping, and via direct tool support such as the Mdbg IL extension)
4. A demo of debugging Reflection.Emit (including interop-debugging), and workarounds for the lack of LCG debuggability.
5. A Just-My-Code (JMC) demo, and that it can be useful to mark various compiler stubs as non-user code. You can add the DebuggerNonUserCode to dynamically emitted code.
6. A quick demo with CLR Profiler.
7. Various best practices.
8. A plug for the ICorDebug/Mdbg forums.

I've attached a zip file of the handout I used and the demos.

FWIW, I was actually hesitant to give the talk because:
- Giving a debugger talk at a compiler lab is a little rough since you're the odd kid on the block. Everybody else is showing their cool language and stuff; and you're not. John Lam kindly helped me refine the agenda and target it for the audience.
- I'm really naive about dynamic languages, so it's easy to feel out of place. (I felt similarly about the AOP presentation I gave)  Using C# examples at a dynamic language lab with Python, Ruby, Boo, APL, + other representatives feels wrong.