Update: Apr 2018

Holy smokes it is April 2018 already! A lot of time has passed since a serious update to RemedyBG for various personal reasons. I decided to thwart this idleness by taking a "vacation" day today to work on the debugger.

Since the last update I've put together a test harness for RemedyBG-Vim that accelerates, well, testing. Having to build, reload Vimscript (if necessary), start the process, run to a breakpoint, verify results, and so on, was getting to be quite tedious.

A simple RemedyBG-Vim test script looks something like:

debug-new-process tests\debug-new-process_command_args\a.exe "{'args': '-o test.h --test'}"
.expect % "{'status': 'Status_Ok'}"
continue-execution
.expect % "{'status': 'Status_Ok'}"
.expect @ -o
.expect @ test.h
.expect @ --test
.expect # "{'type': 'exit-process', 'exitcode': 0}"

From Vim, commands can be sent to the remedybg_vim process via standard-in. In the test script these are lines containing a RemedyBG-Vim command along with arguments packed into a JSON string (note that JSON is only used for the Vim integration; JSON is not, and never will be, used in the formal RemedyBG API). The immediate result from the command, typically a status, is received back via standard out. The ".expect %" you see in the script above is used to check against this result.

Some examples of RemedyBG-Vim commands include

debug-new-process

continue-execution

terminate-process

add-breakpoints-at-function

add-breakpoint-at-source-location

step-over

step-in

step-out

etc.

Other parts of the integration with Vim include writing contents of OutputDebugString into a buffer. These are checked with ".expect @". Also, RemedyBG-Vim can send a message whenever an event occurs (breakpoint was hit, process is terminating, and so forth). These are validated with the ".expect #" statement.

That's all I have for now. Take care all.