• Tips to create good patches

    We've seen the basics about patches: what they are, how they work, and how to create them. Now, I'm going to give you some tips to make your patches better. First: change a single thing per patch, so that it can be handled on its own. For example, if there are two bugs in a single file, create two different patches that fix them independently (and submit the two in different bug reports; see this post).

  • The FluxBox window manager

    GNOME 2.8 is going to be beta real soon now, which reminds me that I should start working on its port to NetBSD through pkgsrc. This means I have to zap all my desktop packages and configuration, and update them one by one. The operation is very, very time consuming, so I will be several days without GNOME installed (well... not really a problem ;-). So I installed FluxBox 0.9.9 today.

  • Creating patches using CVS

    Two days ago I introduced patch files. Let's see how to generate them when the sources you are modifying are controlled by a version management system: CVS. (Note that others also have this feature; just read their documentation.) Recalling the previous post, the common procedure to modify a source file, to later generate a patch, is to keep a backup of the original, like in: $ cp file.c file.c.orig $ vi file.

  • GNOME 2.7.4 released

    The GNOME project has just published the 2.7.4 version of its desktop environment. This version is the last one with "big" changes; the branch has now entered the API/ABI freeze and the module and feature freeze. Further versions will not include new features; just new translations, fixes and general polishment. Check the 2.7 start page for more information.

  • Understanding patches

    A patch is a plain text file that describes the differences (and nothing else) between two different files. They are a very convenient way to provide modifications to programs - you modify the sources, generate a patch and submit it back to the mainstream author - as they describe exactly what you changed. The original can easily check your modifications and decide if they are wrong or not. Patches are very easy to understand, assuming they are in unified format (the only one I'm going to explain here).

  • Compiled vs. interpreted languages

    A friend of mine has asked me today what the difference between compiled and interpreted languages is; so here is the answer for her and anybody else who needs it. A compiled language is one where you have to compile the code before it can be executed. The compilation process, for those that don't know it, transforms the source code into object code; the later can be directly executed by the microprocessor (as it's formed by opcodes), while the former can't.

  • Scheduling timetables

    I've to enrol myself in the university again - 5th semester - this Friday. The first problem is to choose the subjects I want to do; there are a lot of different subjects to choose from. But when chosen, the big problem is to schedule them so that they don't overlap in the timetable. For those who have the same problem, well... only if you are studying at the FIB faculty.