As you know, I’m a Mac, not a PC but recently, an Ars article about Microsoft Visual Studio Code caught my eye. I dropped by the Visual Studio Code website and downloaded a copy. Much to my amazement, I like it.
My work mates know that Emacs is my idea of an integrated development environment. But Mac Emacs ports are clunky. You either have to bring over all the MacPorts goodness or do with one of several adaptations of Emacs to the Mac Aqua UI toolkit. Making the switch between Linux genuine Emacs and Mac Emacs never worked for me.
Every time I tried to get started with Xcode, it was always too much trouble for some quick scripting or most anything else. Xcode really wanted to make Mac OS or IOS graphical applications in the genuine Mac way. Anything else was just too hard to figure out
So I was pleased to see that there was an alternative IDE that was not heavyweight like Xcode or Eclipse (Java — exploit rich Java). So I downloaded Visual Studio Code to give it a try.
Why would a moocher want VS Code?
I’m ODU Institute for Learning in Retirement (a Tidewater VA senior’s club) communications and technology committee chairman. Steady growth of the club over 25 years has forced us to replace our legacy single user office automation (Access homebrew DB app) with a multi-user online professional service.
In making this switch, we have to import 600+ member records from our legacy system into our objective system. The mechanism for doing this is to transfer the data to a MS Excel workbook that our vendor will subject to some script foo to cause our data to appear in our corner of his system.
The easiest way to do the transfer was to create a view containing the records we needed to move, sort the view to make record addition easy, and export the view to a CSV file that we could open in Excel. The trick was that the new system had accounts with contacts, field names changed, some fields like phone numbers had to be correctly formatted and the area code added, etc. So somebody needed to write a record swabbing script. That somebody was the CTC chair since staff couldn’t do it and I was the only programmer volunteer in the club.
Initial Experiences
VS Code downloaded without fuss and runs without fuss. It appears identical in both Windows 10 and Mac OS X. My time is in Mac OS X since I have the Xcode environment in place, git is there, python 2.7 is there and everything is ready to go.
In the past, IDE’s have been too heavy weight to use in a project of this nature. I’d always made do with Emacs, GDB, and Make. This is the first time I’ve successfully used an IDE for a simple scripting project. It’s also my first Mac Python project but the experience is very much like working with the language n Linux Emacs using PDB in an Emacs shell window. Very comfortable to old moochers.
Getting Started on a New Project
Most reviews, tutorials, etc assume that you will be checking out from an existing repository, making a task branch, making some mods, testing, and merging your task branch back into the sprint branch. I was starting with blank disk space so a little preliminary spell-casting was needed.
- Create the project directory
- Create a git repository root in the project directory
- Start VS code and open the repository root
- Add your code file
- Add code
- Test, edit, test, until you feel you have something worth committing.
- Commit.
- Resume work.
Language Support
VS Code requires extensions to become smart about the language (syntax coloring, library functions, compilers and interpreters, running, debuggers and debugging, etc. A built in view makes it easy to locate the modules you need and load them. MS offers a number of contributed Python environments. Each has a peer rating, description, capabilities description etc. It is generally pretty easy to pick the extensions you need. If you are working in a Mac OS compiled environment, you’ll need a debugger interface for either GDB or the LLVM debugger in addition to the language extensions.
Once you’ve loaded all of the needed extensions, restarting VS Code makes them available.
Running Python
So far, I’ve done all my running in the debugger. One oversight of the Python module is that it does not provide a natural way of passing start options to a program. Instead, one creates a running environment by writing some JSON code in a specified format. If you’re not JSON literate, what’s needed is not intuitive. I ended up hard coding the input and output file names in main() to avoid the need to mess with this environment file.
The Visual Debugger
The visual debugger is typical of the breed. It has a code pane, a shell output pane, and to the left, panes for the call stack, watchpoints, active local variables, and function parameters. These last two show the current values of the data passed in the call frame and the locals in the current stack frame. Expanders open structured values to allow inspection of structure members or class attributes.
The code window shows where execution stopped. The left margin has line hot spots used to insert breakpoints. When stopped, mouse hover over a local causes the value to appear in a popup overlay. A button bar at the top of the debugging pane contains a left run button for starting the build/run cycle. A second run button starts execution. Additional buttons step into, step out of, and step to next line. A pause button stops a long running program. A stop button terminates the run. All pretty standard stuff. Button icons are clear but tool tips back up the glyphs on the buttons.
Build Model
I’m not clear on the build model. I believe adding a code file adds it to the build. My only experience so far is with 300 lines of Python in a single file.
Source Code Control
VS Code provides a git view that shows the source directory structure, each file in the directory (as filtered by .gitignore), and the clean/dirty status of the file. A badge shows the number of dirty files in the directory. Controls let you add and remove files from the commit list and make the commit. A text pane provides a place for the check in message. I’ve not had to revert to a prior version so I can’t comment on the tools for doing so. If a file has not been commited, it can easily be reverted to the most recent commit. I’ve yet to have to revert a committed change.
Dismal Manor Dispatches 