on trying to plot any thing in ipython using matplotlib i got the following error

This application failed to start because it could not find or load the Qt platform plugin “xcb”.

Available platform plugins are: eglfs, kms, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.
Aborted (core dumped)

for example the following command will produce the error

ipython -c 'import pylab; pylab.plot()'

matplotlib backend: Qt5Agg

uname -srvmo :: Linux 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux

$ pacman -Q ipython python-matplotlib
ipython 2.2.0-1
python-matplotlib 1.4.0-2

solution :: install libxkbcommon-x11

you may also get the error

You can’t change the terminal in multiplot mode

the following code WILL produce the error:

set multiplot layout 1,2
set term postscript eps enhanced
set out 'a.eps'
plot sin(x)
plot cos(x)

this is an annoyance but just set the term and out variables before you set the multiplot command to get rid of the error message.

set term postscript eps enhanced
set out 'a.eps'
set multiplot layout 1,2 # set 'multiplot' after 'term' and 'out'
plot sin(x)
plot cos(x)

vifm crashes on launch

on archlinux with openbox window manager and no desktop environment

Linux  3.11.1-1-ARCH #1 SMP PREEMPT Sat Sep 14 20:31:35 CEST 2013 i686 GNU/Linux

vifm 0.7.5-1

ncurses 5.9-5

gtk2 2.24.20-1

xterm 297-1

rxvt-unicode 9.18-7

tmux 1.8-1

vifm crashes on launch from the terminal with the following message:

vifm: color_manager.c:47: colmgr_init: Assertion `(color_pair_map != ((void *)0) || avail_pairs == 0) && “Not enough memory.”‘ failed. Aborted (core dumped)

turns out that the crash is being caused by the TERM environment variable being set to xterm-256color or screen-256color in xterm or xterm/tmux combo. in rxvt-unicode the TERM was set to rxvt-unicode-256color. setting TERM to xterm or screen is not causing any crash.

i have been bugged by this for some time now but only found out the reason today.

do not read the startup file ~/.gnuplot

gnuplot reads the ~/.gnuplot file on startup. one can define useful macros or variables in this file so that they are readily available to the user. today i wanted to start gnuplot and bypass the definitions contained in the start up file. one obvious way it to just rename the start up file but that seemed like a bit of a hassle so this is what i came up with after reading the help section for startup

$HOME='' gnuplot

that is just set the HOME environment variable to an empty string before invoking gnuplot. This works because gnuplot looks for the file .gnuplot in the directory defined by the environment variable HOME which is unset just before invoking gnuplot. please note that unsetting HOME this way is only temporary and lasts as long as the gnuplot session. to find out more about startup use the following within a gnuplot session

gnuplot> help startup

$ gnuplot –version
gnuplot 4.6 patchlevel 1

$ bash –version
GNU bash, version 4.2.42(2)-release (i686-pc-linux-gnu)

gsl provides a random number generator that i use in my work. one has to allocate the random number generator at the start of the program and then deallocate the memory at the end of the program. c++11 provides smart pointers which keep track of the objects they point to for the purpose of memory management. when the smart pointer goes out of scope the resource is automatically deallocated when the associated object is destroyed. that’s one headache less for the programmer!

the following code demonstrates how one uses the gsl random number interface in a c-style code and compares it with the use of smart pointers to automatically manage resource deallocation for you.

#include <iostream>
#include <gsl/gsl_rng.h>
#include <memory> // header file for unique_ptr shared_ptr

// c-style usage
void c() {
  gsl_rng *r = gsl_rng_alloc(gsl_rng_taus); // allocation
  std::cout << gsl_rng_uniform(r) << std::endl;
  gsl_rng_free(r); // de-allocation

// c++ style usage with shared_ptr
void cpp_shared() {
  std::shared_ptr<gsl_rng> r(gsl_rng_alloc(gsl_rng_taus), gsl_rng_free);
  std::cout << gsl_rng_uniform(r.get()) << std::endl;

// c++ style usage with unique_ptr
void cpp_unique() {
  std::unique_ptr<gsl_rng, void(*)(gsl_rng*)> r(gsl_rng_alloc(gsl_rng_taus), gsl_rng_free);
  std::cout << gsl_rng_uniform(r.get()) << std::endl;

int main() {
  return 0;

the functions gsl_rng_alloc() and gsl_rng_free() are the memory allocaters and deallocaters respectively.

std::shared_ptr<gsl_rng> r(gsl_rng_alloc(gsl_rng_taus), gsl_rng_free);

in the code fragment above gsl_rng is the type of object r points to. notice how the smart pointer constructor is provided with two arguments 1) the custom allocator gsl_rng_alloc() and 2) the custom deleter gsl_rng_free(). however gsl_rng_uniform() expects a const gsl_rng* argument for which we use the get() member function of the shared_ptr class i.e. r.get() returns a pointer to the gsl_rng object it is pointing to.

std::unique_ptr<gsl_rng, void(*)(gsl_rng*)> r(gsl_rng_alloc(gsl_rng_taus), gsl_rng_free);

this one is a bit ugly looking. notice that unique_ptr requires the specification of 2 template parameters, the type of object being pointed to and the type of the custom deleter. the function gsl_rng_free() is declared as void gsl_rng_free(gsl_rng*) thus the type of this deleter is specified as void(*)(gsl_rng*) i.e. a function which accepts a gsl_rng* and whose return type is void. here again one must use the get() member function to get a reference to the pointed to object.

leave comments, rants and improvements!

the title of this post is misleading … i only talk about commenting and uncommenting region.

this is a small tip for emacs users who want to edit matlab m-files and octave m-files without installing some major mode for editing matlab files. emacs already ships with a built in gnu octave mode and the true hacker will use free software only. but i m no where near being a true hacker thus i often have to write some matlab stuff. i associate all .m files with the octave mode and i have the following line in my .emacs file to achieve that

(setq auto-mode-alist (cons '("\\.m$" . octave-mode) auto-mode-alist))

the major annoyance is that matlab uses the ‘%‘ as the comment char while gnu octave uses ‘#‘. so when editing m files in emacs i often include the following local file variables

% Local Variables:
% comment-start: "%"
% comment-column: 0
% End:

at the end of the m-file. these lines are treated as comments by the matlab interpreter due to the ‘%’ prefix but emacs scans the file and reads these lines and now you can highlight text and use M-x comment-region or M-x uncomment-region. after adding the lines either kill the buffer and visit the file again or hit C-x C-v and then choose the same filename again.

there are probably many good features of the matlab editor but i have not used them much apart from the ability to run the current m file by hitting F5 or setting and clearing breakpoints with mouse clicks. i do like the F5 thingy but i m sure a little bit of elisp can solve that problem. i m sure there are some good major modes for editing matlab files or integrating with matlab but i haven’t explored this area at all.

my emacs version is “GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-04-12 on shirley.hoetzel.info”

problem at hand: how do i use the mouse to copy/paste text in xterm running tmux on PC?

normally you should not have problems selecting text and pasting it with your mouse. everybody knows about left clicking and then dragging to select and copy the text. in order to paste you need to middle click your mouse. however there are certain options which if set will prevent this functionality.

if you have set the following options

  • mouse-select-pane
  • mouse-select-window

you will notice that you are not able to select text at all.

the solution is to use the shift key.

hold down the shift key and then left click and drag across the target text. if you want to now paste the selected text back in to xterm, you must also hold down the shift key and then middle click in order to paste the text.

this is not mentioned in the tmux man pages so i do not think this is a tmux feature. guess this has something to do with xterm, but i m not sure.

xterm version 278-1
tmux version 1.6-2

guly in the comments informs me that iterm users on macosx need to use the option key.

bruceedge pointed out that if the target text area resides in a pane of a split window then trying to copy with this method will also copy stuff from adjacent panes.
to counter this problem one hack is to use the zoom pane functionality. say you want select text from a pane that resides in a split window with other panes. with keyboard focus on the target pane, you simply hit prefix + z to maximize this pane to the entire window. copy what ever it is you want to copy and then hit prefix + z again to toggle back to the previous state.


Get every new post delivered to your Inbox.