In case you’re job hunting, the VB team has a position open for a dev lead:

The Visual Basic team has a long history of delivering great value to our customers, and we are continuing that in the Dev10 release of Visual Studio. We’re looking for a Development Lead to help guide these efforts as well as shape future versions of the compiler.

The Visual Studio Languages group (VSL) develops VB, C#, F#, IronPython and IronRuby. As a member of this product unit, you’ll have the opportunity to work with others developing compilers and IDEs targeting the .NET runtime. You’ll benefit from their experience and contribute best practices and methodologies of your own. In VSL, developers work closely with their QA team, and we are committed to delivering the best value for our customers at very high quality.

As a Development Lead on the Visual Basic compiler, you’ll be the hand at the tiller of VB.NET compiler development. Specifically, you will:

• Manage the day-to-day duties of the compiler and runtime development team, ensuring on-schedule delivery of high quality components.
• Help chart the direction the compiler team takes by prioritizing efforts in coordination with your counterparts in QA and PM.
• Contribute to the design of the Visual Basic programming language.
• Mentor your team of developers to continue their career growth.
• Help shape the engineering environment and procedures in Visual Studio Languages.
• Work closely with the IDE team to help them provide a top notch editing and debugging experience.

To be successful, you’ll need the following:

• A demonstrated aptitude for managing a team of high-caliber developers.
• Excellent communication, collaboration and negotiation skills and the ability to drive open issues to closure.
• Strong architectural sense and a working knowledge of the fundamentals of compiler design.
• Passion for delivering customer solutions and quality software in general.
• Working knowledge of the managed runtime environment is a strong plus.

When we last left ipydbg, it was up to about 200 lines of code. Not bad in terms of overall length, but I started to detect some code smell. I was relying pretty heavily on global variables and the structure of my code made it difficult to control how the debugger was run. I wanted to change ipydbg so it would automatically spin up an MTA thread if I forgot to add the –X:MTA command line parameter. But since by debugger and process objects were global, they’d get created on the main thread of ipydbg, regardless if it was STA or MTA. So for this “release” (I’d say I’m almost to version 0.0.0.1), I decided on focusing on enginering and refactoring rather than new features.

The big new addition is the IPyDebugProcess class, which is clearly the workhorse of the application. All of the previously global variables are now class instance variables on IPyDebugProcess. Input and run along with all the event handlers as well as do_break_event and get_location are now class methods, as they need to access instance variables (setting the break event, accessing the symbol reader dictionary, etc.). Functions that didn’t need to access instance variables (get_sequence_points, create_breakpoint, get_dynamic_frames and get_method_info_for_frame) I left as top-level functions. If they get more complex, I may break them out into their own modules, but for now I left them in ipydbg.py.

The conversion process was fairly trivial. I had to add “self.” lots of places and change the indention level all over but that was pretty much it. Once I finished the conversion, I was able to add the run_debugger function to handle the thread creation, if necessary.

def run_debugger(py_file):
    if Thread.CurrentThread.GetApartmentState() == ApartmentState.STA:
        t = Thread(ParameterizedThreadStart(run_debugger))
        t.SetApartmentState(ApartmentState.MTA)
        t.Start(py_file)
        t.Join()
    else:
        p = IPyDebugProcess()
        p.run(py_file)

if __name__ == "__main__":
    run_debugger(sys.argv[1])

Originally, I tried to put this logic in IPyDebugProcess.run. However, since I’m creating the debugger object in the __init__ function, that meant it would be created on the wrong thread. I could have moved the debugger creation to the run method or move the thread management code to __init__, but I decided to factor that logic into a separate function completely. Felt cleaner that way.