Hacker News Reader

Comment by malkia | Hacker News Reader

Recently I started digging how one could write a debugger for VS, and integration for a language (dynamic one). I stared by looking at pytools, and I was confused by all COM objects, classes, etc. I was not sure at what I point I'll get it to work - do I press F5, and it's installed? Do I make a DLL and it has to be registered?

Now that other plugins are easier - I'm looking now at MonoDevelop and SharpDevelop (Windows Only) but I wish something simpler - like emacs - straight to the core of the system - functions exposed, communication channels right there for you, etc.

Anyway I won't give up, it's just taking too much of my free time.

View on HN

It sounds like there’s two parts of the debugging APIs that you’re confused about – how to get your debugger to run and how to implement the debugger where you have all the AD7 classes and interfaces – it’s certainly not a very discoverable API. On the first part – how your debugger gets used – you ultimately need to have a DLL with your debugger in it which provides the correct registration. Like all things in the managed package framework this is provided by a ProvideAttribute – in this case a ProvideDebugEngineAttribute. So you’ll need a VS package which uses this attribute. There’s some other attributes which might be useful related to debugging and you’ll see those in PythonToolsPackage but I think you can ignore them for now. Once you have a package loaded which provides the debugger to VS you can use VsShellUtilities.LaunchDebugger to launch your debugger and start debugging. In PTVS we do this in DefaultPythonLauncher.cs. The standard VS debug engine sample (http://archive.msdn.microsoft.com/debugenginesample) also ships with an add-in which adds a menu item which does this for the current startup project. Note PTVS is built on this sample but PTVS might be easier to use as its all C# vs the mix of C# and managed C++ in the sample.

The second part you mention is all the AD7 classes. I would actually suggest that you try and ignore these for the most part – at least as you get started. Instead you should look at the PythonProcess class which exposes a simple C# API and a number of events which all of the AD7 classes are simply wrapping. If you completely replace this class with your own you’ll pretty much have a working debug engine. There may be a few things you’ll need to update (for example launch options over in AD7Engine.LaunchSuspended, or parsing expressions to see if they’re valid) but there shouldn’t be much need to look at those classes. And by the time you do need to look at them hopefully you can do it within the context of calls to and from the PythonProcess API and it’ll make more sense.

I hope that helps!

That was very helpful! Thanks Dino!

Reply on news.ycombinator.com