Monday, 28 October 2013

I completed my transfer of snippets from Smipple to GitHub, so now they are available again. I guess I need to fix the embedded code in my old posts as well at some point.

But no sooner had I thought Mygists would fix the problem of finding the Gists than it's down. Hopefully not for long. The good thing is that Mygists is open-source and in any case gist.github.com has a usable API so I can always set up my own service if needed.

Now I wonder if I should move my small projects from Gitorious.org there? A gist can include more than one file so at least a couple of those projects would work well.

Friday, 25 October 2013

I had completely forgotten that GitHub supports this as well. They just call these snippets Gists. I think this pretty much is a no-brainer now. GitHub versions the files , allows branching and I can even download all Gists on a go, although it requires a bit of scripting (hey ho). The only thing I miss right now are tags.

And the same code as an embedded Github Gist looks like:

We have a winner!

EDIT: I just found out MyGists. It supports tagging the gists with hashtags, so now the last big problem is solved - how to find the script I want after I have a large number of them.

I tried the snippet databases mentioned in my last post. I dropped DZone quickly without even trying it because it just looks ugly. SourcePod was interesting, but not really a database as there is no login. You can only find your old scripts from the same machine you submitted them.

That leaves Snipt and Snipplr. Here's what the embedded code looks like for Snipt:

I was eventually more drawn toward Snipplr but I'm starting to lean toward Snipplr for two reasons: first it looks like not much is happening at Snipplr any more. Last blog post was two years ago. API documentation is in one initial blog post years back. Snipt on the other hand seems to still be under active development. And Snipt is open source! Snipplr is still being used but it's still a bit disconcerning.

There are things in Snipplr I wish Snipt had. The embedded output for one, line numbers are nice. It also supports versions for each snippet.

Neither supports direct Git support. It would be nice to be able to pull your scripts occasionally so that if the service stops working I still have them readily available.

Wednesday, 23 October 2013

Dang. Smipple.net has been down for a while and it looks like fixing it isn't a top priority for the maintainer. So I need to find a new home for my code snippets and hope I can get them out of smipple at some point.

Thursday, 17 October 2013

I have now setup Vim to take more advantage of the quickfix window and I think it's a pretty neat way.

First I changed cscope to use it instead of the default way which is a bit bulky by adding the following to .vimrc:

set cscopequickfix=s-,c-,d-,i-,t-,e-

This in itself is cool because now I can just jump between the hits.

Of course quickfix window is already used when I build the software. Just to make moving around this list I did the following mappings:

map <A-p> :cp<CR> map <A-n> :cn<CR>

So now I can use Alt-p and Alt-n to move between items in the quickfix window. The nice thing is, that this now also applies to any cscope lists! So instead of searching, then selecting a number to see a single context of, say, a function call, I can jump in the code to see all the hits with those keys.

And just to top this off, I also added the following:

map <A-P> :colder<CR>map <A-N> :newer<CR>

Which means that I can now build, then maybe do a cscope search to check something (say, a function prototype) and quickly move between these two quickfix windows with those keys!

As a sidenote vim-airline messes up my GVim window badly, especially when using those quickfix windows so I had to move back to Powerline. Shame, because Airline had plenty of stuff going for it.

Friday, 20 September 2013

I finally got around trying gdb inside vim and after a bit of tweaking it works.

Basic instructions are easy enough except for a few things. First, the readline mentioned is a package called libreadline-dev. Secondly, at least in Ubuntu 12.04 I needed to upgrade gdb to version 7.5 with

Because without this I got errors about some terminal issues. But after this running "clewn -va " and then "file
Having said that, for some reason command output is still only printed inside gdb, such as variable values. The buffer mentioned in the clewn documentation seems to be missing.

Friday, 13 September 2013

I had this annoying and weird problem with copying stuff from GVim to other apps. I just couldn't get it to work, no matter how many instructions I followed. I verified with xclip that none of the choices worked ("*y, "+y or painting with mouse). Funnily enough copying to GVim did work.

I still don't know what the full problem is, but I noticed I had been using vim-athena which does have xterm clipboard enabled (every instruction tells to check this first and most also end there) but not mouse. I don't know what that mouse option does since the mouse did work.

In any case, I installed vim-gtk2 and I got this to a working condition. Well, mostly. I can use the X clipboard ("*y) and I can use the mouse, as long as I click directly to the correct window with the middle mouse button. So I can't first activate the other window with the LMB or this doesn't work. Also system clipboard ("+y) still doesn't work.

But I can live with this, this was by far the most annoying problem I have had with vim so far. This is a deviation from other apps, since I can select other windows before copying the X clipboard.

So if you have the same issue with GVim in Linux, try the other versions of graphical vim and see if it helps.

Thursday, 16 May 2013

Don't know what went wrong, but I tried setting a breakpoint in web2py's web interface and the application hanged completely (i.e. I couldn't open it any more no matter what I tried). The only thing I could think of was to restart apache, but it wouldn't restart because the ports were already bound.

I don't know if these are related, but in the end I had to kill -9 all apache2 processes and then run /etc/init.d/apache2 start to get apache up. Application is also now running.

Thursday, 18 April 2013

I've been learning to use Vim for past two weeks and I'm finally getting to grips with it. Learning the basics is the easy part (there are plenty of tutorials) but to get it to work in a real project is a bit more work as it involves installing a host of plugins etc.

I'm getting there as well and this is a sort of first look at what I have found so far. I might follow-up on this if there are any new interesting findings.

Firstly, I tried Janus, which is a collection of plugins rolled into one plus some modifications. Not a good idea, it adds far too much stuff and you have no idea what.

Now I think I have a usable setup although there are still lots of small things to improve. And I know there are useful plugins that I should add.

Plugins

To start with, a plugin manager is a good idea. Pathogen is the older one, Vundle newer. I opted for the latter. Vundle helps with the installation etc. issues although I did find that using the built-in installer doesn't seem to work reliably. It says it installs the plugin, but you can't use it. So it's better to find the address for the plugin and adding this to .vimrc.

So far I have added the following:

NERDTree - File explorer. I mapped F5 to toggle.

vim-fugitive - Plugin for Git.

vim-gitgutter - Shows changes made to file in the left column compared to HEAD. I toggle this with F4.

cvim - C plugin for Vim. Includes a host of useful stuff for C coding, like file templates, commenting (mark an area and hit \cc to comment and \co to uncomment for instance) etc.

Gundo - Vim undo explorer. Vim has a more complex undo system than most (it can branch) and this visualises the undo path. I have mapped this to F7.

Tagbar - Shows tags for current file in a window. I have mapped this to F6.

CCTree - Call graph visualizer. This shows the call graph of selected item, either forward or reverse. I have mapped this to F8.

Powerline - Makes the status bar much better. Looks better, includes stuff like current git branch and colours it depending on vim mode.

Minibufexpl - A very compact buffer explorer.

OmniCppComplete - Code completion.

SuperTab - Improves tab. I use this with OmniCppComplete.

There are some other stuff I have done as well, but those add the most value. There have been a few hickups on the way and I still do. Plus I have only started configuring the key mappings.

UPDATE: I have found that so far I haven't used cvim or Gundo at all. Both are theoretically nice ideas but I find the C standard functions with Google and Gundo just doesn't seem to fit with my way of thinking.

Handling files in multiple directories

To make CCTree, tags and completion to be useful was to be able to add 3rd party sources to the search tree and in a way that I can actually have more than one project. There are some project oriented plugins but I haven't looked at them yet. I managed this more easily in the following manner.

First of all I wrote a script that creates a file with all the files I'm interested in. It looks something like

Which would leave out any files in a "backward" directory. This works for C files, C++ would just search for cpp and hpp files.

I already have the paths defined in my build environment so this was simple. I save the output to cscope.files in my main source directory (=basically root directory of my own project).

Then I can just call

ctags --C-kinds=+p --fields=+aS --extra=+q -L cscope.files

or

ctags --C++-kinds=+pl --fields=+iaS --extra=+q -L cscope.files

for C++ files. l in the "kinds" parameter is not probably needed, it includes info for local variables. Nice if you need to browse through code with long methods.

To generate the tags file. For cscope I'm so far fine with just cscope -R.

For CCTree I need to do :CCTreeLoadDB

This way I can have separate tags files for separate projects and I only need to add

tags+=./tags

into my .vimrc to get OmniCppComplete to see all the tags in this project.

I have omitted basic installation of these plugins from this post because it would make this very long and this info is easily available already. The stuff I have explained here needed a bit more digging than just following the instructions even though it wasn't that hard either.

Powerline

Powerline needed a bit of tweaking before it started working. Here's how.

First of all, the Vundle line in .vimrc needs to be

Bundle 'Lokaltog/powerline', {'rtp': 'powerline/bindings/vim/'}

Then I cloned the patched fonts repository to ~/.fonts and run fc-cache -fvin it.I originally tried to save just one font with Save As in my browser but this somehow messed the file and fc-cache wouldn't even recognize it.

Lastly I added these lines to .vimrc:

" For Powerline

set encoding=utf-8

if has("gui_running")

set guifont=Droid\ Sans\ Mono\ for\ Powerline\ 11

endif

let g:Powerline_symbols = 'fancy'

I liked Droid the most of the fonts available. It's possible to add your own patched fonts as well, but I didn't find any need for that.

Minor tweaks

I have made a couple of other minor tweaks (and this is something I guess vim users never stop doing). Firstly, I like to see which files I have edited but not saved so I added this to .vimrc.

It's also nice to be able to move between windows easily, especially when you work with some of the plugins I have installed.

" quick moving between windows

map j

map k

map h

map l

It's really annoying that Vim keeps creating all these temporary and swap files in the current directory so

set backupdir=$HOME/.vim/_backup//

set directory=$HOME/.vim/_temp//

Usually I want Vim's current dir to be the one I opened the file in so I added a mapping just for changing that:

nnoremap ,cd :cd %:p:h:pwd

And what does all this look then? Below is an example screenshot. Obviously I don't keep all those windows open all the time, this is just for demonstration. Left-most panel is Gundo. Top part shows the undo tree and bottom part the changes done in this revision. Next is NERDTree, then code window and the right-most window is TagBar. You can also see OmniCppComplete in action, the window above the code window is showing info about the selected struct member. Also check out the status line

Second example shows more stuff. Left-most window is the CCTree window. It shows a forward trace from main(). Above the code window is vim-fugitive's window after :Gstatus, which shows the same output as "git status" on the command line. Top-most small area is the minibufexplorer. In the code window you can also see that I have added the file header comment. This is shown by gitgutter.

Monday, 25 March 2013

I kept hitting this same issue every time I updated packages in my Ubuntu at work. We have a certain build system that for some reason requires libtool version 2.2.6 rather than 2.4.2 that comes with Ubuntu. With the newer version, the build fails.

So I kept fixing this with

apt-cache showpkg libtoolsudo apt-get install libtool=2.2.6b-2ubuntu1

Finally I found a solution that should prevent Ubuntu from upgrading the version: