Monday, January 24, 2011

Knock, Knock... Who's there?... VoraX 2.8

Hey folks! I feel bad for VoraX 2.7. It really had a short life, just a week... If you're the kind-hearted type then you may choose to keep VoraX 2.7 and make it happy. But, would you be also happy without these new VoraX 2.8 goodies? Well, let's see...

First of all, VoraX 2.8 is faster because it has a redesigned OS interface. This becomes obvious especially on Cygwin. Till now, there was an annoying delay immediately after a statement was finished executing. That was because another call was made in order to get connection information, which was further used to update the VoraX title. In VoraX 2.8 this is no longer true, the connection info is gathered in one step, as part of the statement execution itself.

Another useful feature is the monitoring capability of the results window. If you have a long running statement and you want to be notified when it's done then this is perfectly doable in VoraX 2.8. And because a picture worths one thousands words, below is a screen-shot showing this feature on my Ubuntu box:


Just put the following snippet into your .vimrc:
" Nice notification for my monitored long runinng queries
function VoraxNotification()
  let cmd = "notify-send -i 'terminal' 'VoraX' 'Execution of your monitored statement on ". 
            \ &titlestring . " has just finished.'" 
  exe 'silent! !' . cmd
endfunction
let g:vorax_notify_command = "call VoraxNotification()"

On Windows I have no idea how to configure this but I guess there are some "cool" command line programs to display those annoying balloons in your tray.

And that's not all. Did you noticed the re-polished status line for the results window? Much better, isn't it?

As far as bug fixes are concerned I recommend you to upgrade because this version has a fix for a quite critical bug reported by Shaun Batterton. The bug description goes like this: if your statement has an "end" somewhere in between then a "/" will be appended. For example, if you execute something like:

alter tablespace muci_tbs add datafile size 100m autotextend on;

behind VoraX will rewrite (in a wrong way because of the bug) as:

alter tablespace muci_tbs add datafile size 100m autoextend on;
/

I know it's stupid but because the statement has an "end" (in autoextend) we end up adding two datafiles which, of course, is not what we've meant. Thanks Shaun for this bug report.

There's also another bug fix in connection with virtualedit setting but that's not something to pay too much attention in this post.

Okey, that's all. You may find additional details about these new features within the VoraX updated documentation.

Monday, January 17, 2011

VoraX 2.7 Released

By this post I want to let you know that VoraX 2.7 is available for download. The most important improvement this version brings out to light is a better way to define your key mappings for VoraX commands. No more VoraX event handler bullshit! Starting with this version you may define these mappings using a few g:vorax_key_for_* global variables. For example, my vimrc file contains now the following:

let g:vorax_key_for_exec_buffer = "<F8>"
let g:vorax_key_for_exec_sql = "<Leader>e"
let g:vorax_key_for_exec_one = "<Leader>1"
let g:vorax_key_for_describe = "<Leader>d"
let g:vorax_key_for_describe_verbose = "<Leader>D"
let g:vorax_key_for_explain_plan = "<F5>"
let g:vorax_key_for_explain_only = "<S-F5>"
let g:vorax_key_for_fuzzy_search = "??"
let g:vorax_key_for_goto_def = "gd"
let g:vorax_key_for_toggle_logging = "<Leader>l"

Of course, you're free to choose whatever you want. You are no longer bound to the default VoraX key mappings.

There are also a couple of bug fixes. They are detailed into the changelog.

Wednesday, January 5, 2011

VoraX on Vim 7.3

Apparently the VIM pack from Lucid repository has a nasty bug which causes VoraX to crash on my Ubuntu box with VTALRM signal (Virtual timer expired). I can't reproduce this behavior at will but it happens quite often to encounter this crash which, of course, is very annoying as I also loose all the work I did into my unsaved buffers.

So, I decided to compile the latest VIM version (7.3 at the time of writing this post) in order to get rid of this bug. Below are the steps I've done:

1. remove the actual VIM packages:
FITS\alec@tia ~ $ dpkg --list | grep vim
vim-common                            2:7.2.330-1ubuntu3                    Vi IMproved - Common files
vim-gnome                             2:7.2.330-1ubuntu3                    Vi IMproved - enhanced vi editor - with GNOM
vim-gui-common                        2:7.2.330-1ubuntu3                    Vi IMproved - Common GUI files
vim-runtime                           2:7.2.330-1ubuntu3                    Vi IMproved - Runtime files
vim-tiny                              2:7.2.330-1ubuntu3                    Vi IMproved - enhanced vi editor - compact v

FITS\alec@tia ~  # sudo apt-get remove vim-common vim-gnome vim-gui-common vim-runtime vim-tiny

2. install dependencies
sudo apt-get install libncurses5-dev libgnome2-dev libgnomeui-dev \ 
libgtk2.0-dev libatk1.0-dev libbonoboui2-dev \ 
libcairo2-dev libx11-dev libxpm-dev libxt-dev

3. download vim7.3 from: ftp://ftp.vim.org/pub/vim/unix/vim-7.3.tar.bz2

4. unpack the archive: tar -jxvf vim-7.3.tar.bz2

5. configure, make and install:
cd vim73/src/
./configure --with-features=huge --enable-gui=gnome2 --enable-rubyinterp
make
sudo make install

Simple as that! VoraX seems to be stable now. I didn't experience any VTALRM crashes since then.

Update 1: Ups, today I received a VTALRM crash. I think the problem is not Vim but ruby itself. On Ubuntu ruby is compiled with libthread which may cause troubles. I will try with a pthread-less ruby to see if it makes any difference.

Update 2: I asked Vim community for help here. With the provided patch I didn't experience any new VTALRM crashes.

Update 3: The fix is included in Vim 7.3.118.