Debugging In Vim

A year ago, I have switched to Vim for my C++ development stuff. At the beginning it was hard to manage the new environment but after some uncomfortable weeks I felt deep in love with Vim. Today, I wouldn’t go back and deal with all these stupid cursor operations. But until last night there was a tiny thing that bothered me. No debugging in Vim.

Okay, debugging programs in C++ is a bit different from other programming languages. I would like to say 80% of bug detections could be done by static analysis. The debugger isn’t that important in the most cases. In the last year I used gdb or lldb at the command line and I was pretty satisfied with the results, except with the procedure necessary to set breakpoints. A simple click into the source code would be so much easier. Yesterday, after a long long debugging session, my frustration exploded and I was set to change something. This was harder than expected. So, I decided to write some notes into my fancy and successful blog.

Before we can start I would like to provide some notes about my environment: I’m using MacVim 7.3 on OSX 10.8 and compile all my programs with LLVM/Clang. I have found four opportunities to get debugger integration in Vim: vim-lldbvimgdbclewn and pyclewn. vim-lldb makes use of lldb and therefore it was my first choice, but after some tests I realized this is not the right thing for me. I guess lldb is much better without this vim-lldb shebang. vimgdb, clewn and pyclewn are for the gdb. According to the table on the pyclewn website, surprise surprise, pyclewn provides the most functionalities. Hence, I decided to go with pyclewn.
I found out that pyclewn is not compatible with the preinstalled version of gdb on OSX 10.8. We need to install another version of gdb. This can be done with homebrew.

brew install gdb

Now we have two versions of gdb on the system. Apple’s version is located at /usr/bin/gdb and homebrew’s version at /usr/local/bin/gdb. To guarantee that the /usr/local/bin/gdb will be selected by default, we have to change the /etc/paths file.

sudo vi /etc/paths

Make sure that /usr/local/bin is above /usr/bin. In my case I end up with this:


gdb needs to be code-signed to have the privilege to attach to other processes. I have found a good how-to here. Thus, quoted from there:

Start Keychain Access application (/Applications/Utilities/Keychain Open menu /Keychain Access/Certificate Assistant/Create a Certificate… Choose a name (gdb-cert in the example), set Identity Type to Self Signed Root, set Certificate Type to Code Signing and select the Let me override defaults. Click several times on Continue until you get to the Specify a Location For The Certificate screen, then set Keychain to System. [...] Finally, using the contextual menu for the certificate, select Get Info, open the Trust item, and set Code Signing to Always Trust. You must quit Keychain Access application in order to use the certificate [...].

Now we can sign the new gdb executable:

codesign -s gdb-cert /usr/local/gdb

A reboot was necessary before the code signing worked for me.

Vim starts pyclewn as a standalone program connected to Vim with a netbeans socket. Therefore our Vim version needs the netbeans integration feature. Another dependence is autocmd. Your Vim versions must support theses features but that should already be the case if you are using the preinstalled Vim version on OSX 10.8 and MacVim 7.3 like me. To be sure you should find +autocmd and +netbeans_intg in the version info.

/Applications/MacVim-snapshot-65/mvim --version | grep "+autocmd\|+netbeans_intg" 
/usr/bin/vim --version | grep "+autocmd\|+netbeans_intg"

Congratulations! Now we can download pyclewn and install it how it is described on the website by the following commands. I’m not sure but I believe OSX has Python 2.7 preinstalled. Hence the *.py2.tar.gz should be okay.

tar xzf pyclewn-1.11.py2.tar.gz
cd pyclewn-1.11.py2
export EDITOR=/usr/bin/vim
sudo vimdir=$HOME/.vim python install --force

Finished! Now you can open Vim and start pyclewn with :Pyclewn. If you came across this blog post I suppose that you already know that pyclewn will not turn your Vim into an Eclipse or something like that. It doesn’t shelter you to grapple with gdb’s commands. I would say my environment is still expert friendly, which means I’m not really sure if my frustration level will reduce. No, I’m just kidding. Pyclewn provides the gdb command line directly in Vim and gives the possibility to bind gdb commands to keys and so on. After decades of configuring it will fit perfectly. Hopefully.

Please find my current Vim configuration here.

Aesthetic Driven Development

This year I quit my job and went to the university to study computer science.
As any student I had to attend a programming course. I got in touch with programming beginners and their problems. Since then, I ask myself how I’m actually solving problems. It feels like opening VIM and simply get things done. But what’s behind?
This is my first try to write it down.

Weeks ago I have listen to a really interesting interview with an astronomer. He talked a lot about research methods and pointed out, that astronomer and mathematician be guided by aesthetic when they don’t know an exact way to proceed with their research.
They have no other choice as trust the feeling what is the right direction in this moment. This is an aesthetic feeling. Some essential parts of the string theory were created this way he sad.
I think we can adopt it fully to the development of applications or technical systems in general. In slightly larger projects, it is almost impossible to know from the beginning how the software will work in the end. So lets do it aesthetic driven.

The industry of software development is always in hurry. If you did some code reviews, I guess you’ll agree with me that nobody has enough time to think about his or her own code.
I’m sure everyone can remember one of these moments when you recognize that the current development goes a wrong way for a long time and the best idea would be to start over from the beginning. I believe to start from scratch is a good thing if you have enough time. But most of the time it’s too late when you reach this point, especially if you don’t have a lot of practice.
How can we avoid this? To do this, we need a strategy that tells us when the development is starting to turn in a wrong direction.

I would say it’s an aesthetic feeling which tells you something like: “That code smells!” I believe every programmer should care about this feeling. It can help to identify bad ideas at an early stage. Our aesthetic feeling can also help us here as well.

It’s hard to get a good understanding of software aesthetics. Especially when you’re not very experienced. But I’m sure this is one of the most important things to be good in this job.
I think the best way to improve the aesthetic feeling is to get your hands dirty. Doing it right, doing it wrong, doing it in another way, but doing it.

Just code and talk about it. Review code from your colleagues and let them review your code. You’ll get a better understanding what’s brilliant and what’s not. Talking about code in this level is also a good way to share knowledge. So, waste your time with that. I guess studying programming strategies like dynamic programming, heuristic methods and so on is also a good method. They will teach you aesthetic solutions for complex problems and I believe it‘s a good idea to think about how these strategies were invented to improve your own aesthetic feeling about development.

If I’m working on problems I always follow the same procedure. First of all I jump into that problem and get my hands dirty. Write prototypes, create unit tests, and talk about that problem or just start to implement code. I trust my aesthetic feeling what the right way is. The important thing is to recognize when the development is leaving the world of perfect aesthetics. In this moment I simply have to delete the icky part and find another solution. After doing this two or three times I’ll come up with a very good solution. In the first moment this might sound like a waste of time, but the goal is to identify aesthetic problems as fast as possible. Most of the time this is only in my head.

The bottom line is trust your feeling during software development! It will tell you a lot more than you expected.

I’ll try to substantiate this in the future. Probably.