How to make a grad student freak out
May 20, 2012So that grad student has just submitted his thesis and you are invited to review it. With these quick tips, you can test the limits of the student’s willpower, and make his degree a little more deserved by putting him up for some constructive mind games.
Chamada de grupos de usuários Debian no Brasil
March 23, 2012 - No comments yetUm tempo atrás o servidor de listas do CIPSGA, onde ficavam as listas dos grupos de usuários Debian, subiu no telhado.
A partir de hoje vamos recriar as listas dos grupos de usuários na infraestrutura do próprio Debian. Pra isso, vamos utilizar o projeto debian-br no alioth e criar as listas lá dentro.
A lista principal, usada pra articulação dos grupos de usuários regionais (ou seja, a lista antes conhecida como “debian-br”), vai ser a debian-br-geral
O padrão de nomes para as listas regionais vai ser o seguinte: debian-br-gud-$uf, onde $uf é a sigla do estado. Por exemplo, as listas para o Debian-RS e Debian-BA já foram criadas, e são chamadas debian-br-gud-rs debian-br-gud-ba, respectivamente.
Para solicitar a criação de novas listas, favor criar um novo tíquete no projeto debian-br, do tipo “Support Request”.
Infelizmente, não se tem backup sequer da lista de e-mails inscritos; por isso, além de recriar as listas vai ser necessário que todo mundo se inscreva novamente. Depois da criação da lista do seu estado, favor espalhar a notícia!
Thesis submitted
February 28, 2012 - 5 commentsLast Friday, after 5 long years, I have finally submitted my PhD thesis. It was quite a relief, more or less as if an elephant was taken off my back.
An English title for my thesis would be Structural Complexity Characterization in Software Systems. Here is an abstract:
This thesis proposes a theory to characterize structural complexity in software systems. This theory aims to identify (i) the contribution of several factors to the structural complexity variation and (ii) the effects of structural complexity in software projects. Possible factors in the structural complexity variation include: human factors, such as general experience of the developers and their familiarity with the different parts of the system; factors related to the changes performed on the system, such as size variation and change diffusion; and organizational factors, such as the maturity of the software development process and the communication structure of the project. Effects of structural complexity include higher effort, and consequently higher cost, in software comprehension and maintenance activities.
To test the validity of the proposed theory, four empirical studies were performed, mining data from free software project repositories. We analyzed historical data from changes performed in 13 systems from different application domains and written in different programming languages.
The results of these studies indicated that all the factors studied influenced the structural complexity variation significantly in at least one of the projects, but different projects were influenced by different sets of factors. The models obtained were capable of describing up to 93% of the structural complexity variation in the projects analyzed.
Keywords: Structural Complexity, Software Maintainance, Human factors in Software Engineering, Mining Software Repositories, Theories in Software Engineering, Empirical Software Engineering, Free/Open Source Software Projects.
Those who read Portuguese can check out the actual thesis text as a PDF file.
Most of the studies discussed in the thesis are presented in English in papers I have published during the last years.
My defense is going to be on March 23rd. If you happen to be at Salvador at that day, please feel cordially invited.
A visual cheat sheet for ANSI color codes
January 28, 2012 - 8 commentsNow and then I want to output some ANSI color escape codes from software I write, and I always end up doing some trial-and-error to figure out the exact codes I want. Sometimes it’s overkill to add a dependency on an existing library that already deals with it, or the language I am using does not have one.
There are a lot of listings of the ANSI color codes out there, but I couldn’t find one that matches the actual codes with the resulting effect in a visual way. Even the Wikipedia article has a colored table with the actual colors, but I have to lookup manually which code combination produces which color.
So I spent a few minutes to write a shell script that prints all useful combinations, formatted with themselves. This way I can quickly figure out which exact code I want to achieve the desired effect.
The code for now is very simple:
#!/bin/sh -e
for attr in $(seq 0 1); do
for fg in $(seq 30 37); do
for bg in $(seq 40 47); do
printf "\033[$attr;${bg};${fg}m$attr;$fg;$bg\033[m "
done
echo
done
done
Is there a package in Debian that already does that? Would people find it useful to have this packaged?
update: it turns out you can find some similar stuff on google images. It was a quick and fun hack, though.
update 2: Replacing echo -n with printf makes the script work independently if /bin/sh is bash or dash. Thanks to cocci for pointing that out.
Life after exec()
January 9, 2012 - 4 commentsFrom the “not necessarily big news, but still useful” department.
The situation: for Very Good Reasons™1, you want to replace your current process by calling exec, but you still want to have the chance to do something after the process you exec()ed finishes.
This is a simple technique I just came up with: just before replacing the current process by calling exec(), you fork() a process in the background that will wait for the current process id to disappear from the process list, and then does whatever you want to do.
A simple proof-of-concept I wrote is composed of two bash programs: wrapper and real.
real is really simple: it just waits a few seconds and then prints its process id to the console:
#!/bin/bash
sleep 5
echo $BASHPID
wrapper is the program that handles the situation we want to exercise: it replaces itself with real, but still has the chance to do something after real finishes. In this case, wrapper notifies the user that real finished.
#!/bin/bash
echo $BASHPID
real_program_pid=$BASHPID
(
while ps -p "$real_program_pid" >/dev/null; do
sleep 0.1s
done
notify-send 'real program finished'
) &
exec ./real
One nice property that wrapper explores is that when exec() starts real, it really replaces wrapper, and therefore has the same process id (in this case accessible by bash in the $BASHPID variable). Because of this, the background process that wrapper starts just before the exec() call already knows which process it has to watch for.
The actual code for waiting is not optimal, though. I cannot use waitpid() (the wait builtin in bash), since real is not a child process of wrapper. I went with a brute force approach here, and I am pretty sure there is a cheaper way to wait for a random PID without a busy loop (but that wasn’t the point here).
1
update: I am aware of the classic fork()/exec() pattern. My Very Good Reasons™ include the fact that I can’t control the flow: I am writing a plugin for a program that calls its plugins in sequence, and after that, calls exec(), but my plugin is interested in doing some work after exec() finishes.