Stefaan Lippens' webface

When programming, lint checking your source code can be useful to detect low level issues like syntax errors, undefined or unused variables. The PHP command line interpreter has an option -l/--syntax-check to do a syntax check of the provided PHP file, instead of executing it:

$ php -l file_with_syntax_error.php 
PHP Parse error:  syntax error, unexpected T_VARIABLE in file_with_syntax_error.php on line 5
Errors parsing file_with_syntax_error.php

Unfortunately, it only allows to check one file at a time. For example, the following does not work as expected:

$ php -l file1.php file2.php file_with_syntax_error.php 
No syntax errors detected in file1.php

If you want to lint-check (a complete tree of) multiple PHP files, you have to use some kind of loop (e.g. in Bash) to check them one by one.

I recently was faced with this issue, but also wanted to have some parallelism, to speed up the process by putting multiple cores a work, instead of checking one file at a time. After googling a bit I found the following (command line) solutions.

Finally! I found how to get the keyboard shortcut for code completion working in Eclipse on Mac OS X. At work, on Linux, I use CTRL-SPACE all the time in Eclipse. Unfortunately that did not work on my MacBook: CMD-SPACE triggers the spotlight search widget and CTRL-SPACE is tied to the Quicksilver launcher in my case.

How unpleasant I may find it, sometimes I have to use some tools in Matlab at work. Today I stumbled on a problem with compiling MEX-files written in C++ on my Ubuntu 8.04 (Hardy Heron) box. To illustrate, I'll use the example C++ MEX file mexcpp.cpp provided with Matlab (Matlab r2007a) in the extern/examples/mex/ folder.

Out-of-the-box compilation with

mex mexcpp.cpp

gave the following warning:
Warning: You are using gcc version "4.2.4". The earliest gcc version supported with mex is "4.0.0". The latest version tested for use with mex is "4.2.0". To download a different version of gcc, visit http://gcc.gnu.org

Despite the warning a MEX-file mexcpp.mexglx was generated. However, its usage resulted in the following:
Invalid MEX-file '/foo/bar/mexcpp.mexglx': /matlabdir/sys/os/glnx86/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /foo/bar/mexcpp.mexglx).
As a sidenote: compiling MEX-files written in C also caused the warning message, but using the compiled MEX-files did not fail.

At work, I'm trying out BeatRoot, an application written in Java, for its BPM estimation capabilities. The data set I'm working with is encoded in MP3 format and getting this Java tool to work with the MP3 data was not an easy ride.

When you're working on a software development project where not all parties use the same code style conventions or editor setting (like tabs vs. spaces, removing trailing spaces, etc), the signal to noise ratio of a source code diff can be a bit frustrating. Luckily, most diff programs have an option to ignore whitespace changes, for example -w or --ignore-all-space in GNU diff or colordiff.

The internal diff engine of Subversion also offers this option (since version 1.4 if I'm not mistaken), but it looks a bit weird to use it:

svn diff -x -w ventrolucator.cpp

At first, it seemed annoying, but now I really like that git uses a pager when it has to present something (e.g. a log or a diff) that is longer than your screen. Git even provides a built in option --color to show you a diff with helpful colors. I use this option all the time and made a shortcut dic for it with the following command

git config --global alias.dic "diff --color"

Also possible is to edit your ~/.gitconfig directly so you have something like the following in there:

[alias]
        di = diff
        dic = diff --color

Now I just do

git dic

and I get a nice paged and color highlighted diff.

Subversion keyword substitution is a nice concept, but the revision number refers to the revision the file was last changed, not the current version of the file. If you have for example a project with several files (e.g. main.c, pol.c, mol.s) and in main.c you have code that should render the current version of the program (like printf("Revision: $Revision$");). That revision keyword in main.c will not be expanded if you change and commit pol.c or mol.c, so the rendered revision will be wrong in that case.

The standard unix/linux tools for filtering/changing strings (or patterns) in files from the commandline are sed and awk. But what if you want to change strings in-place in the files without the burden of creating new files and replacing the old ones afterwards?

The "perl pie" is a handy one-liner for these occasions:

perl -p -i -e 's/Jesus/Elvis/g' bible.txt

This will replace in file bible.txt all occurences of 'Jesus' with 'Elvis' in-place.

More info:

• Unix Tip: EAT YOUR PERL PIE
• Debian Administration: Search and replace across many files with a perl one-liner

With the python module inspect, one can inspect (no kidding) the run-time python stack. Among other things, this makes it possible to get the name of the current function or callers. Handy for logging or debugging purposes. A simple script to illustrate:

import inspect
# functions
def whoami():
    return inspect.stack()[1][3]
def whosdaddy():
    return inspect.stack()[2][3]
def foo():
    print "hello, I'm %s, daddy is %s" % (whoami(), whosdaddy())
    bar()
def bar():
    print "hello, I'm %s, daddy is %s" % (whoami(), whosdaddy())
johny = bar
# call them!
foo()
bar()
johny()

output:

hello, I'm foo, daddy is ?
hello, I'm bar, daddy is foo
hello, I'm bar, daddy is ?
hello, I'm bar, daddy is ?