Truth, Computing and Fail

I have decided to move some of my personal projects to Google Code so that it’d give me some impetus and make me get off my lazy ass and actually put some real effort into the things I like.

Er, not really. It’s more of a selfish decision. Right now I want other people to read and criticize my code so that I’d know where I’m going wrong and correct myself. Nothing’s more dangerous than complacency.

As a starter, I have uploaded the tiny mpd now playing plugin I wrote for xchat about an year ago when I was learning socket programming in python. Showing the current playing track was too easy. Right now I want it to become more like an interface to mpd that provides basic controls sitting in the comfort of xchat.

I named the project mpd-xchat

PS: Just after I had uploaded the code, I found a project by the name of xchat-mpd

I hope to add one more project in the next few days

So much for late night coding. Yesterday I missed out on a very important part about setting the hard limits on resources. But you need to have a superuser process to achieve this. Referring to the code of exec.c in the previous post, put in this after line no. 18.

limit.rlim_max =1;

This is actually the hard limit and as the man page says, it acts as a ceiling for the soft limit i.e. rlim_cur. The advantage being that if the process exceeds the limit and yet continues running such as by handling the SIGXCPU signal in the previous example, this time a SIGKILL will be issued which would force it to terminate.

Now compile exec.c as usual and run it as root. You won’t see any output as we set the hard limit equal to the soft limit.

• Soft limit reached, SIGXCPU sent
• Process tries to handle it
• At the same time the hard limit i.e. the ceiling for soft limit is reached too. So a SIGKILL is sent and the process terminates before any output.

References

setrlimit(2) man page

This might seem trivial at first sight but you have no idea how darn happy I’m to see this works . So happy that I decided to blog about it. I already hear trumpets blowing in the distance.

Here is what I was worried about:

Normally, exec() is carried out in a forked process. Setting resource limits on a forked process is straightforward using setrlimit(). But I was apprehensive whether those limits would hold once I exec() another binary image within that forked process, and it wouldn’t be overstating it if I said I was about to front kick my laptop in joy .

I tested by limiting the amount of CPU time(RLIMIT_CPU) that a running process is allocated since this would be the easiest to test IMO. The signal delivered to the process when it exceeds the CPU time limit is SIGXCPU.

Since this is all that is to it, wasting no more words, let’s get our hands dirty.

The program in which a process is forked and exec() is run (exec.c):

#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

int main()
{
    int pid;
    int rv;

    if (!( pid=fork() ))
    {
        struct rlimit limit;
        getrlimit(RLIMIT_CPU, &limit);

        limit.rlim_cur = 1;

        setrlimit(RLIMIT_CPU, &limit);

        execl("./inf","inf",NULL);
    }
    else if(pid)
    {
        wait(&rv);
    }
    else
        printf("Error forking\n");

    return 0;
}

The program whose binary image is specified in exec() (inf.c):

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void handler(int signum)
{
    if (signum == SIGXCPU)
        printf("Caught SIGXCPU signal, exec in peace\n");
}

int main()
{
signal(SIGXCPU, handler);
while(1);
return 0;
}

Now compile
$gcc -Wall exec.c -o exec
$gcc -Wall inf.c -o inf

and run
$./exec

You’ll see SIGXCPU being handled which means the resource limit is working!

I’ve spent the past few weeks changing the look and feel of my Vim environment. One fine day I decided to explore some :colorscheme while I was on GVim apart from the classic ’slate’ that I always use.

Now, now. I can already see purists scoffing at me for using GVim. The main reason for me using GVim is just for the occasional visual treat. While you are on the terminal and working on Vim, you don’t really have much choice of beautifying things within the editor itself. You rather have to make some changes to the terminal profile about the background/font color, font to be used and all that stuff.

Coming back to where I started off, I googled and found a few color schemes. This caught my eye because it claimed to be The last vim color scheme you’ll ever need. Apparently this was supposed to give GVim a TextMate kinda look but applying the colorscheme is only the first step. You need to set the proper fonts and background too. I suggest you checkout the vimrc and gvimrc of the author of the linked post.

After all was done, I didn’t find the final outcome to be that impressive. In addition to GVim being buggy on occasions like no input displayed in the command mode, this time it would get stuck after I’d scroll down or up about 20 lines for like a second. Besides, it wasn’t looking too great. See for yourself.

Now it was time to make some changes to gnome-terminal and see if it suited my tastes. As usual none of set backgorund=dark and colorscheme ir_black showed the necessary changes within Vim. This part is easy. Just make a new terminal profile with the following options:

• White on black for foreground/background
• Font:Monaco with size 12

After this just add the following lines to your .vimrc

set background=dark
colorscheme ir_black


Switch to the new profile, open up Vim and see the difference in the richness of the colors and better font rendering.

Bonus Tip

If you are a python coder, you might want to look into this post by Samuel Huckins on making Vim a complete IDE for python development. I’ve been using the NERDTree and code folding plugins mentioned there and they have been of really great help.