Antonio Terceiro's contents tagged with "english"

Ruby 2.0 released, with multiarch support^W^W^W^W

Sun, 24 Feb 2013 15:31:48 -0300

Ruby 2.0 was released today. This new version of the language brings some very interesting features, and according to the core team, an effort has been made to keep source level compartibility with Ruby 1.9.

Debian packaging is under way and should hit NEW soon. During the last few days I gave more attention to getting the new multiarch support fixed upstream than to the packaging bits, but the remaining packaging work should be pretty much about housekeeping.

Next steps from a Debian point of view (after Wheezy is out) include:

add Ruby 2.0 support in gem2deb (should be trivial).
check what packages need fixing to support Ruby 2.0, and which are broken beyond repair.
figure out how to better exploit a multiarch-enabled Ruby.

Now let’s get back to fixing RC bugs and getting Wheezy released. :-)

UPDATE 2013-03-06: actually the multiarch support is broken in 2.0.0, and the bugs I reported were only fixed in trunk. I will probably backport those fixes in the Debian package.

Today I am turning 20 ...

Wed, 21 Nov 2012 11:09:18 -0200

… in hexadecimal.

I have been waiting for a long time to be able to make this joke, and I will still be able to do it for the next 9 years! :-)

Wheezy is Coming

Thu, 28 Jun 2012 10:13:20 -0300

The original image (in wallpaper resolution) was made^Whacked by my friend Aurélio .

How to make a grad student freak out

Sun, 20 May 2012 10:43:59 -0300

So 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.

Thesis submitted

Tue, 28 Feb 2012 21:44:52 -0300

Last 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

Sat, 28 Jan 2012 11:17:28 -0200

Now 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()

Mon, 09 Jan 2012 10:43:56 -0200

From the “not necessarily big news, but still useful” department.

The situation: for Very Good Reasons™¹, 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).

¹ 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.

Laptop fun, or "WTF, HP?"

Mon, 12 Sep 2011 19:56:58 -0300

A couple of weeks ago my old laptop decided to rest forever, and I was forced to impose some economic pressure onto the consumption of the planet resources by acquiring a new one. Fortunately this happened while I am still here in Canada, where it is reasonably cheaper to get a decent laptop than it is in Brazil. Although I did not have the budget I wanted for buying a really kick ass laptop, I was able to buy a decent one, an HP Pavilion G6 1B74CA.

I went on 4 different shops with a USB stick loaded with Debian Live to check whether all the hardware would work ok. I always asked one of the salesman before rebooting the laptops, but it was funny to see the reactions of the different employees who came by to check what I was doing: some of them barely noticed that GNOME was not Windows XYZ, and and some asked whether I was hacking the laptops.

Unfortunately, I wasn’t able to find a single laptop in which the wireless worked out of the box with the Squeeze kernel, which sucks. I searched over the internet a lot, and it seems that even the vendors recommended by the FSF do not provide laptops with wireless cards that work without non-free blobs.

Other issue I had was with the Intel graphics. After the kernel enables the modesetting, the backlight goes to the minimum and it looks like you have no video. There are a couple of workarounds in the internet, and the one in which you add “acpi_osi=Linux acpi_backlight=vendor” to the kernel parameters makes the laptop turn on by itself in the morning. This is probably caused by broken ACPI handling in the BIOS, who almost always is written by people on crack.

The other issues I had were related to the keyboard. First, the BIOS came by default with “Access keys mode” enabled, which means that by default pressing F2-F12 actually activated the “multimedia keys” instead of the real function keys. It was disapointing to hit F12 and have my wireless turned off. After disabling this in the BIOS setup, it was OK.

Well, not quite: for some reason, Fn+F4 did not generate the expected keycodes. After some research on the internet, I found a interesting Ubuntu bug . It seems that the “latest and greatest” version of Windows starts its video setup application via the Meta+P shortcut (“Meta” is the actual name of what Windows people call “the Windows key”). Guess what the morons writing the HP BIOS did … yes, they made the keys Fn+F4 (where F4 has “video setup” as its “multimedia key”) generate the keycodes for Meta+P!

It would be a lot easier for everyone in the world if the people at Microsoft just make their stuff listen to both Meta+P and the “video setup” keycode, which is generated by every laptop out there, to activate the Windows screen setup thing. This way the very smart dudes writing BIOS at HP wouldn’t need to make Fn+F4 generate the keycodes for Meta+P and break every single desktop that is not procuced at Redmond.

Handling upstream patches with git-export-debian-patches

Sat, 13 Aug 2011 22:03:41 -0300

These days I briefly discussed with a fellow Debian developer about how to maintain upstream patches in Debian packages with Git, what brought me to rethink a little about my current practices. What I usually do is pretty much like point 4 in Raphael's post "4 tips to maintain a “3.0 (quilt)” Debian source package in a VCS": I make commits in the Debian packaging branch, or in a separate branch that is merged into the Debian packaging branch. Then I add the single-debian-patch option to debian/source/options so that a single Debian patch is generated, and include a patch header that points people interested in the individual changes to the public Git repository where they were originally done.

My reasoning for doing so was the following: most upstream developers will hardly care enough to come check the patches applied against their source in Debian, so it's not so important to have a clean source package with separated and explained patches. But then there is the people who will actually care about the patches: other distribution developers. Not imposing a specific VCS on them to review the patches applied in Debian is a nice thing to do.

Then I wrote a script called git-export-debian-patches (download, manpage), which was partly inspired by David Bremner's script. It exports all commits in the Debian packaging branch that do not touch files under debian/ and were not applied upstream to debian/patches. The script also creates an appropriate debian/patches/series files. The script is even smart enough to detect patches that were later reverted in the Debian branch and exclude them (and the commit that reverted them) from the patch list.

The advantage I see over gbp-pq is that I don't need to rebase (and thus lose history) to have a clean set of patches. The advantage over the gitpkg quilt-patches-deb-export-hook hook is that I don't need to explicitly say which ranges I want: every change that is merged in master, was not applied upstream and was not reverted gets listed as a patch. To be honest I don't have any experience with either gbp-pq or gitpkg and these advantages were based on what I read, so please leave a (nice ;-)) comment if I said something stupid.

I am looking forward to receive feedback about the tool, specially about potential corner cases in which it would break. For now I have tested it in a package with simple changes agains upstream source, and it seems fine.

Playing with JPEG quality and file size

Sat, 06 Aug 2011 23:39:49 -0300

This is probably no news at all for graphics/image processing experts, but its something I've just learnt myself and I thought it would be fun to share.

I am writing a static HTML photo algum generator and was a little suspicious of the size of the generated JPEG images. I thought "well, these JPEGs should not be that large ..."

I did some quick research and found out that ImageMagick uses JPEG quality 92 by default and was curious how file size would vary as I changed the output quality.

Then I took an image and produced thumbnails for it with the "JPEG quality" parameter ranging from 1 to 100 to check 1) how the file size varies with quality and 2) how much quality actually makes any difference when viewing the images.

To generate the thumbnails with varying quality, I did the following:

$ for i in $(seq -f %03g 1 100); do convert -scale 640x480 -quality $i /path/to/original.jpg $i.jpg; echo $i; done

Then I generated a data file by calculating the size of each file with du and piping the results through sed and awk:

$ du -b [0-9]*.jpg | sed 's/.jpg//' | awk '{ print $2 " " $1 }'

The generated data file looks this, with JPEG quality in first column and file size in bytes in the second column:

Regarding to file size, it seems like between 1 and 50, file size grows sublinearly with quality. Beyond that, the curve reaches an inflection point and grows in a way that looks, if not exponentially, at least polynomially.

The above plot was produced in a R session that looked like this:

$ R

R version 2.13.1 (2011-07-08)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: i486-pc-linux-gnu (32-bit)

R é um software livre e vem sem GARANTIA ALGUMA.
Você pode redistribuí-lo sob certas circunstâncias.
Digite 'license()' ou 'licence()' para detalhes de distribuição.

R é um projeto colaborativo com muitos contribuidores.
Digite 'contributors()' para obter mais informações e
'citation()' para saber como citar o R ou pacotes do R em publicações.

Digite 'demo()' para demonstrações, 'help()' para o sistema on-line de ajuda,
ou 'help.start()' para abrir o sistema de ajuda em HTML no seu navegador.
Digite 'q()' para sair do R.

> png()
> data <- read.table('points.dat')
> quality <- data[[1]]
> quality
  [1]   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18
 [19]  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36
 [37]  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54
 [55]  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72
 [73]  73  74  75  76  77  78  79  80  81  82  83  84  85  86  87  88  89  90
 [91]  91  92  93  94  95  96  97  98  99 100
> filesize <- data[[2]]
> filesize
  [1]  20380  20383  20634  21106  21551  22012  22469  22878  23323  23715
 [11]  24103  24494  24952  25327  25725  26127  26507  26886  27216  27550
 [21]  27917  28288  28627  28945  29271  29583  29919  30280  30516  30813
 [31]  31099  31367  31679  31873  32232  32538  32704  33072  33324  33443
 [41]  33860  34055  34253  34633  34804  35074  35216  35491  35871  35935
 [51]  36030  36443  36743  36898  37120  37382  37726  38077  38307  38581
 [61]  39002  39270  39700  39962  40388  40762  41086  41629  42062  42544
 [71]  43048  43392  44062  44824  45023  45682  46532  47347  47833  48701
 [81]  49612  50423  51694  52637  53635  55243  56340  58304  59709  62162
 [91]  64207  66273  70073  74617  79917  86745  94950 105680 128158 145937
> plot(quality, filesize, xlab = 'JPEG Quality', ylab = 'File size')
> 
Save workspace image? [y/n/c]: y

Looking at the actual generated thumbnails, somewhere after quality > 60 I stopped noticing the difference between increasing quality factors. Settling with a default quality of 75 seems to be good enough: the resulting static HTML album generated from a folder with 82 pictures dropped from 12MB with the default ImageMagick quality factor to 6MB with quality 75, with very little perceivable image quality loss.

Hello, Planet Debian

Fri, 22 Jul 2011 23:58:49 -0300

Hello, world! So, now this blog is being syndicated on Planet Debian, and I decided to write something to introduce myself.

I was born in Salvador, Bahia, Brazil. I am married to Josy, a wonderful person; we do not have any kids yet, but anyone can notice we both discretely drooling when close to small children.

I have a passion for building things, and making things work. Programming happens to be the better building toy that someone already invented.

I became am official Debian Developer a little more than one week ago, but I have been working in the project for some time already. In the very beginning I was involved with the Perl group, but now almost all my work is in the Ruby team.

I am a PhD student at Federal University of Bahia under supervision of professor Christina Chavez. My research involves three topics I am just fascinated about: Free ("and Open Source") Software, Software Design and Empirical Software Engineering. I am investigating whether it is possible to explain the variation in Structural Complexity by analyzing developer attributes. I want to answer questions such as "do developers with more experience in a project produce more complex code?", or "do developers that focus on a single part of the project produce more complex code than developers who work on the entire project?".

As part of my PhD research I have been working on analizo, a multi-language source code analysis and visualization toolkit. I plan to write specifically about it in a later opportunity.

My other job is running my own company, Colivre, together with several other great people. Colivre is a cooperative, which basically means that everyone who works there is also an owner of the company. We provide web solutions, in special social networking environments, social media websites and the like. Working on (and with) free software is our premise at Colivre, and most of our work involves either Noosfero or Foswiki.

Right now I am taking some time off from Colivre to be able to concentrate on (and finish!) my PhD. Until late September I live at the beautiful Vancouver, BC, Canada, where I am currenly a visiting reasearcher at the Software Practices Lab at UBC under supervision of professor Gail Murphy.

So that's it, I hope to post interesting stuff here and to get your feedback whenever you find it's worth. I also maintain a microblog at identi.ca, where you'll find shorter (and more frequent) updates.

Building a Debian package out of a Rubygems' .gem file

Sun, 17 Oct 2010 13:02:27 -0200

This post is sort of a status update on ongoing work in Debian's Ruby packaging infrastructure, i.e. the tools used to package Ruby libraries and applications (not the Ruby interpreters themselves) for Debian. We have recently added two new utilities to ruby-pkg-tools:

gem2tgz, a tool to convert .gem files into source tarball suitable for being used as a Debian upstream tarball. This is needed because unfortunately several useful Ruby libraries and applications are only officially released in the .gem format.
a ruby buildsystem for debhelper, which will automatically build standards-compliant Debian Ruby packages.

To follow the steps in this post, you'll need to build ruby-pkg-tools from the pkg-ruby-extras team subversion repository (e.g., you need ruby-pkg-tools 0.18, which is not in the archive yet). You can also browse the source.

First you have to download a .gem file. Let's took fast_gettext as an example. Enter a temporary directory and download the latest version of the .gem:

$ wget http://rubygems.org/downloads/fast_gettext-0.5.10.gem

Now we need to convert that .gem file into a source tarball to be used by the Debian package:

$ gem2tgz fast_gettext-0.5.10.gem libfast-gettext-ruby-0.5.10.tar.gz

Then uncompress the source tarball, and change to the extracted source directory:

$ tar xzf libfast-gettext-ruby-0.5.10.tar.gz
$ cd libfast-gettext-ruby-0.5.10/

Inside the source directory, you need the generate the Debian package files. For now, you'll use good old dh_make:

$ dh_make -f ../libfast-gettext-ruby-0.5.10.tar.gz --single

Then we have an almost "ready" Debian package. It still misses several documentation issues that need manual checking, but for the sake of the example in this post it is good enough already.

I normally remove all the example files dh_make generates for us:

$ rm -f debian/*.ex debian/*.EX

The next step is to change debian/rules so that it will use our custom Debhelper build system. It's just a matter of adding an extra argument for the dh call. The final rules file must look like this:

#!/usr/bin/make -f

%:
        dh --buildsystem=ruby $@

Now we build the package. I normally use debuild for that.

$ debuild

After the build lintian will complain a lot, because our package has lots of unchanged dh_make boilerplate, but as fas as this post is concerned, the point is that the package will install the code correctly.

You can check the contents of the package with debc, to make sure everything will be where it should. Our custom debhelper buildsystem is installing Ruby libraries to /usr/lib/ruby/vendor_ruby, so it will available to all Ruby versions installed.

Now that the package is built, you can install and test it:

$ sudo dpkg -i ../libfast-gettext-ruby_0.5.10-1_i386.deb
[...]
$ irb -rfast_gettext
>> FastGettext.add_text_domain 'mutt', :path => '/usr/share/locale'; 1
=> 1
>> FastGettext.text_domain = 'mutt'
=> "mutt"
>> FastGettext.locale = 'pt_BR'
=> "pt_BR"
>> include FastGettext::Translation
=> Object
>> _('Delete')
=> "Remover"

I tried the above with both irb (currently Ruby 1.8's irb) and irb1.9.1 (Ruby 1.9.2's irb), and it worked fine.

This custom buildsystem still misses proper handling for some special cases:

C extensions. They must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/
Libraries that are specific to a single Ruby version. This is the case for example of libraries that got included in Ruby 1.9.x itself but are still useful for Ruby 1.8, or even C extensions that do not compile under Ruby 1.9.x. Those libraries must be installed under /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/ for pure-Ruby libraries and /usr/lib/ruby/vendor_ruby/${RUBY_VERSION}/${ARCH}/ for C extensions.
Applications. Normally an application should use a single and well-known Ruby version, e.g. either Ruby 1.8 or Ruby 1.9.2. So that no matter which is the default Ruby version (the one started when ruby is invoked), the application will work the same.

Next steps include providing a dh-make-ruby tool that will convert the extracted tarball into a proper Ruby Debian package. This tool will eliminate the need for all the manual steps listed above after the gem2tgz invocation and before the package build (debuild).

dh-make-ruby will use the Rubygems metadata that gem2tgz puts inside the generated tarball to automatically fill important files in the package, such as debian/control and debian/copyright. It will also generate a debian/rules that is ready to go for most packages. Hopefull the generated source package will also as lintian-clean as possible.

There is an existing implementation of dh-make-ruby out there, which will be surely taken into account when building our own.

There is also lots of documentation that needs to be written/updated, and all help we get will be appreciated.

A better svn diff

Wed, 06 Oct 2010 17:01:58 -0300

Since I started using git, every time I need to use Subversion again I suffer. The output of `git diff` is so nice compared to the one produced `svn diff` that it hurts. I've alredy been struggling with that previously.

Now I think I've achieved the perfect solution to make `svn diff` behave just like `git diff`. I've documented it in this post hoping to help other poor souls like me who still have to use Subversion now and then.

Step 1: install colordiff. It's installed on Debian, so the installation required me no effort at all.

Step2 (optional): configure colordiff to use your preferred set of colors. My ~/.colordiffrc contains the following, to match the same colors used by default by `git diff`:

banner=no
color_patches=no
plain=off
newtext=darkgreen
oldtext=darkred
diffstuff=white
cvsstuff=darkyellow

Step 3: create a script to be called by Subversion when running `svn diff`. In my case, I called it svn-diff and stored it in ~/bin (which is in my $PATH), but you can put it in /usr/local/bin or any other directory that is in your $PATH. The contents of ~/bin/svn-diff is the following:

#!/bin/sh

 colordiff -u -L "${3}" -L "${5}" "${6}" "${7}"

After creating the script, you need to make it executable:

$ chmod +x ~/bin/svn-diff

Step 4: tell Subversion to use your script instead of plain diff on `svn diff`. To do that, locate the "helpers" section in your Subversion configuration file (~/.subversion/config), and set the diff-cmd setting to the name you gave to your custom script (svn-diff in my case):

[helpers]
diff-cmd = svn-diff

There is only one thing missing with regard to `git diff`: the nice pager behaviour. Git invokes that system pager in a way that less will receives the options "-FRSX". These options make less exit imediately if the output fits in one terminal screen and output the ANSI sequences (and thus colors) generated by colordiff in raw format, among other things. I couldn't find a way to emulate this: since `svn diff` will call our custom diff command once for each changed file, we can't call the pager inside svn-diff. A comprimise is doing `svn diff | less -FRSX` , or setting the LESS environment variable to 'FRSX' and doing simply `svn diff | less`.

That's it! Now you can almost forget you are using Subversion (until you need to do some merging).

Getting more out of Gwibber

Tue, 06 Jul 2010 10:25:17 -0300

Gwibber has frustrated me as a microblog reader. A minor issue I have with it is that sometimes I just can't post/reply through it. I don't know whether it is related to the microblogging services have crashed, which is not Gwibber's fault, but it would be nice if if at least warned the user with a "could not send your post" error message.

But the major issue I have with it is that I cannot see enough back in time: since I definitively do not check it all the time, I often lose posts that were not done in the last 24 hours. I tried to solve this by unfollowing people that post a lot, but it did not solve the problem.

I've had read that the Twitter API , which is supported by StatusNet at identi.ca, supports a count argument, which indicated how many posts will be provided, and that it defaults to 20.

Then I did what every programmer should do: look at the source code. I looked inside the implementation of identi.ca account support in Gwibber source code, and found out that it already uses this parameter, although there is no user interface for setting it. Every account has a receive_count attribute that defines how many posts will be fetched from the servers, and it defaults to 20.

While there is no UI for receive_count, you'll need to set this attribute directly in gconf. I used gconf-editor for that, but there are a couple of other options out there. Go to apps/gwibber/accounts, find your accounts, and add a new integer key/value pair there, with key "receive_count", and the value you want to.

Distraction-free writing with vim and awesome

Fri, 04 Jun 2010 15:57:35 -0300

I've recently learn about distraction-free text editing from Lucas, and really liked the idea. Turns outs it is pretty easy to implement it with my beloved vim text editor.

Removing all distraction while using the console vim is trivial. I just need to switch my awesome workspace to full-screen layout, and that's it. The terminal window running vim will take the entire screen space, and then it's me and vim. No menus, no buttons, nothing.

Achieving the same effect with gvim is a bit more tricky: besides putting the awesome workspace to use full-screen layout, you have to turn off both the menus and the toolbar. To do that, I mapped the F11 and F12 keys to turn the menus off and on, respectively, by adding the following lines to my ~/.gvimrc:

map <F11> :set guioptions-=m<CR>:set guioptions-=T<CR>
map <F12> :set guioptions+=m<CR>:set guioptions+=T<CR>

You can check out the result in the above screeshot. Yes, that is my entire screen.

The tip for toggling menu and toolbars came from the vim wiki.

You ask me: what's the point of running gvim if you are disabling the menus and the toolbar? Several reasons: the fonts look nicer in gvim, the colors are better than the console ones, and I can turn the menu back on if I need (for example to do something I do not remember the command for).

A little more impressive

Sun, 16 May 2010 12:51:53 -0300

Impressive is a slide presentation application. Not a presentation authoring application, it does very well a single job: presenting. To create the slides, you can use LaTeX and Beamer, or export a PDF file from OpenOffice.org, or (put your favorite slide authoring tool here). Impressive is packaged in Debian, and probably in other operating systems as well, so using it requires no effort at all.

Impressive has very nice features, such as an overview screen displaying thumbnails of all slides, zooming, highlighting specific areas of the slides, a spotlight that follows the mouse and even the possibility of scripting your presentations with arbitrary Python code.

Another great impressive feature is its collection of transition effects.I've just sent out a small contribution, adding a new transition effect: fade in/fade out: the current slide is faded out to black, and then faded the black in the next slide.

This seems to be the default transition effect in Apple's Keynote, and I must admit that it is very cool and I wanted it. :-)

So, with the patch I've just sent out, I hope to contribute with making impressive a little more impressive than it already is.

update(17/05): I already got a reply from Impressive's author Martin Fiedler, and the transition was already included in the subversion repository. His implementation is a lot better than mine. :-)