cesarbs

Some Common Lisp implementations (and I believe other languages’ also, but I don’t know of any) are incremental compilers, which means they are able to read Lisp code during program execution, compile it and make it immediately available for execution, without requiring the program to be restarted.

I find that quite amazing, so I decided to try it out for myself. The following code contains a function that generates an array of opcodes for a function that returns an integer passed as the first function’s argument. After calling the function, it is possible to convert the returned pointer to a function pointer and call it.

#include <stdio.h>
#include <stdlib.h>
 
char* makefunction(int ret)
{
    char* opcodes = malloc(6);
    opcodes[0] = 0xb8;
    *((int*)(opcodes + 1)) = ret;
    opcodes[5] = 0xc3;
    return opcodes;
}
 
int main()
{
    char* code = makefunction(20);
    int (*f)() = (int(*)()) code;
    int a = f();
    printf("%d\n", a);
    return 0;
}

That should print “20″ to the console.

What’s happening here? Here’s a function that returns 2 when called:

int f(void)
{
    return 2;
}

This is the output of objdump -d after compiling it:

f.o:     file format elf32-i386

Disassembly of section .text:

00000000 :
   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	b8 02 00 00 00       	mov    $0x2,%eax
   8:	5d                   	pop    %ebp
   9:	c3                   	ret

The first two instructions, as well as the fourth (push, mov and pop), are stack-related code the compiler generates for all functions. So what really accomplishes the task of returning 2 is the following opcode sequence:

b8 02 00 00 00 c3

By checking this reference, I verified that b8 moves a value to the EAX register, which is commonly used to store function return values. The other 4 bytes correspond to the value that should be stored in that register. c3 is the opcode for ret, which returns from a function call (Captain Obvious, 2010).

Now let’s see what makefunction does:

1. Allocates memory for 6 opcodes:

   char* opcodes = malloc(6);

2. Writes the opcode for moving a value into the EAX register into the array:

   opcodes[0] = 0xb8;

3. Writes the actual value that should be moved into EAX

*((int*)(opcodes + 1)) = ret;

4. Writes the opcode for the ret instruction

   opcodes[5] = 0xc3;

5. Returns the array of opcodes:

   return opcodes;

Back in main, The pointer to the opcode array is converted to a function pointer of the appropriate type:

int (*f)() = (int(*)()) code;

And then called as any other function:

int a = f();

This generates a call instruction, which causes the current value of the IP register to be saved and the execution to jump to the specified address. In this case, that address corresponds to the opcode array’s address, which contains valid instructions that will be executed by the processor.

The difference here in relation to regular function call code is that the code is being fetched and executed from the data section of the program, instead of the code section. I’m almost sure that will crash on processors with the NX bit enabled, but I haven’t checked it. Anyways, that’s an extremely simple example of how it is possible to generate machine code during run time and execute it right away.

I’ve just spent two days trying to figure out what was wrong with an OSG application I was not being able to build on Mac OS X 10.6. After importing all necessary OSG frameworks, I kept constantly getting linker errors saying the symbols OpenThreads::Atomic::operator--() and OpenThreads::Atomic::operator--() couldn’t be found.

It turns out it was a binary compatilbility issue. I built the 32-bit Debug Carbon configuration of OSG 2.8.3 from the Xcode project files that come in the source distribution (not the ones generated by CMake). The problem is that the Deployment Target is set to Mac OS X 10.4 in that project:

As far as I know, there’s no binary compatibility with libraries targeted at Mac OS X 10.4 or older starting with SDK 10.5. So, I was trying to build an application using the 10.6 SDK, but linking it to libraries built for Mac OS X 10.4.

Therefore, the solution was very simple (took me 2 days to find it, however). I just had to change the Deployment Target in the OSG Xcode project settings to 10.5 and rebuild it:

I first changed the Deployment Target to 10.6, but I wasn’t able to build OSG then. So I changed it to 10.5. I didn’t take the time to figure out what was wrong when targeting at 10.6, though.

I first tried it this way:


$ cd OpenCV-2.0.0
$ mkdir build
$ cd build
$ cmake ..
$ make


But it failed. I got lots of errors when trying to link highgui to the Carbon libraries. The problem is that Carbon is 32-bit only, and by default OpenCV was being built for 64-bit.

Here the (very simple) solution to that:


$ CFLAGS="-arch i386" CXXFLAGS="-arch i386" cmake ..
$ make


When I started to learn about Lua, I found it a little odd that the numeric 0 (zero) value is treated as a true boolean value by the interpreter, which was different from all other programming languages I had worked with.

However, it turns out that it makes a lot of sense to have 0 as a true value, and that’s when you take short circuit expressions into account.

For those who don’t know, short-circuit expressions are used to conditionally select values without having to code that selection into an if-elseif-else structure. Short-circuit expressions are built using logical (and, or, not) operators. The and operator returns the value of the first false expression, or the last expression, in case all others were true. The or operator returns the value of the first true expression, or the last expression, in case all others were false. Here are a few examples in Lua:

Code:

word = 1 < 2 and "hello" or "world"
print(word)

Output:

hello

Code:

level = 10 > 9 and 2 or 4
print(level)

Output:

2

Now, consider the following Lua short-circuit expression:

bit = math.random() < 0.5 and 0 or 1

Running it many times will psuedo-randomly assign both 0 and 1 values to the bit variable:

Code:

for i=1,8 do
    bit = math.random() < 0.5 and 0 or 1
    print(bit)
end

Output:

0
1
1
1
0
0
1
0

Now, consider what happens when we try to do the same thing in Python 2.6:

Code:

import random
for i in range(8):
    bit = random.random() < 0.5 and 0 or 1
    print(bit)

Output:

1
1
1
1
1
1
1
1

The first operand of the and expression is always false, because 0 is considered to be a false boolean value by the Python interpreter.

Even though one could argue that it’s just a matter of knowing how to rewrite such logical expressions, I believe it’s good not having to worry about undesired behavior caused by 0’s in short-circuit expressions. It allows me to write expressions just as they come to my mind, which makes me more productive than if I had to re-arrange them.

Here’s how you translate the following C code

int max(int a, int b)
{
    return (a > b ? a : b);
}

to Python:

def max(a, b):
    return a if a > b else b

The general syntax is:

TRUEVAL if CONDEXPR else FALSEVAL

Note: I’m not 100% sure, but I think that only works starting from Python 2.5.

When reading single bytes from a file in C, one must pay attention to the correct usage of feof() and fread(). At first, the following piece of code seems to work correctly:

const char *filename = "hello";
unsigned char byte;
FILE *fp;
 
fp = fopen(filename, "rb");
 
if (!fp) {
    printf("could not open file\n");
    return 1;
}
 
while(!feof(fp)) {
    fread(&byte, 1, 1, fp);
    printf("%02x\n",byte);
}
 
fclose(fp);

Suppose the file “hello” has the following contents:

0000000: 68 65 6c 6c 6f 0a                                hello.

(which is the string “hello” followed by an LF)

When the code above is run, the following output is produced:

68
65
6c
6c
6f
0a
0a

Notice the last character seems to be read twice. The problem is that feof() only returns true after attempting to read past the end of the file. In order to fix this “read-twice” behavior, the return value of fread() must be checked:

if(!fread(&byte, 1, 1, fp)) {
    break;
}

Note: Using feof() as the while condition is kind of redundant here. In this situation, one could simply use while(1) and the behavior would be the same.

Update: A much better solution was given by my friend Bryan:

const char *filename = "hello";
unsigned char byte;
FILE *fp;
 
fp = fopen(filename, "rb");
 
if (!fp) {
    printf("could not open file\n");
    return 1;
}
 
fread(&byte, 1, 1, fp);
while(!feof(fp)) {
    printf("%02x\n",byte);
    fread(&byte, 1, 1, fp);
}
 
fclose(fp);

I am not really a C++ programmer. I usually code in C, and I think all C++ I’ve ever written involved a couple of vectors and maybe one or two classes. So what I’m writing here is certainly old news for C++ programmers.

The other day, while I was reading this essay about the Liskov Substitution Principle, I was intrigued by a situation presented in page 4, which deals with class inheritance and method overriding.

Methods that can be overriden must be declared virtual in C++. I really didn’t know about that. I am used to Java’s behaviour, which I illustrate below:

/*
 * A.java
 */
 
public class A {
 
	public void bar() {
		System.out.println("bar");
	}
}
 
/*
 * B.java
 */
 
public class B extends A {
 
	public void bar() {
		System.out.println("Bar!");
	}
}
 
/*
 * C.java
 */
 
public class C {
 
	public void call(A o) {
		o.bar();
	}
}
 
/*
 * Main.java
 */
 
public class Main {
 
	public static void main(String [] args) {
		A a = new A();
		B b = new B();
		C c = new C();
 
		c.call(a);
		c.call(b);
	}
}

The code above will produce the following output:

bar
Bar!

If I wanted to do the same thing in C++, I would have to write it this way:

#include <iostream>
 
class A {
public:
	A() {}
	virtual ~A() {}
	virtual void bar() { std::cout << "bar" << std::endl; }
};
 
class B : public A {
public:
	B() {}
	virtual ~B() {}
	void bar() { std::cout << "Bar!" << std::endl; }
};
 
class C {
public:
	C() {};
	virtual ~C() {};
	void call(A &o) { o.bar(); }
};
 
int main(int argc, char *argv[]) {
	A a;
	B b;
	C c;
 
	c.call(a);
	c.call(b);
 
	return 0;
}

The output will be the same as the Java program, but pay attention to the virtual modifier placed before the declaration of the bar method in A. If I remove it, the output will be:

bar
bar

Even though B declares a method called bar, it is completely shadowed by the implementation inherited from A. In my opinion, Java’s behaviour is a lot more intuitive. I wonder how many people might have spend hours, maybe days, looking for a bug in a C++ program when the problem was that a method was not declared virtual and method calls weren’t occuring as expected.

I talked about this with Otávio, and he found out C# has a similar characteristic. In C#, a method must be declared as virtual for its subclasses to override it AND the subclasses must use override when overriding the method. Here’s the code he provided me:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace ConsoleApplication1
{
   class Alice
   {
       public virtual void sayHello()
       {
           Console.WriteLine("Hello, world");
       }
   }
 
   class Bob : Alice
   {
       public override void sayHello()
       {
           Console.WriteLine("Hello, world!");
       }
   }
 
   class Echo
   {
       public void say(Alice toto)
       {
           toto.sayHello();
       }
   }
 
   class Program
   {
       static void Main(string[] args)
       {
           Alice a = new Alice();
           Bob b = new Bob();
           Echo e = new Echo();
 
           e.say(a);
           e.say(b);
       }
   }
}

Some people argue that this makes code clearer, but I’m not convinced. Why not make overriding implicit?

I have set up an SVN repository for QuickSynergy at my recently-acquired Dreamhost hosting. Their control panel is great and setting everything up was very easy.

However, it doesn’t install any repository browsing tool such as ViewVC, and I really enjoy using that kind of thing. So I went after it and managed to install it successfully at http://svn.cesarbs.org/viewvc.cgi. The installation steps are quite simple and are listed below. I am assuming you have set a up a separate subdomain exclusively for your SVN repositories, such as svn.yourdomain.org.

1. Download the latest ViewVC package from the official website.
2. Extract the package somewhere in your home directory at Dreamhost.
3. Enter the viewvc-version directory and run the viewvc-install script.
4. Install ViewVC somewhere in your home directory.
5. Edit the /path/to/viewvc/viewvc.conf configuration file.
6. Point svn_roots to the path to your SVN repository (look for the svn directory in your home directory).
7. Set default_root to svn.
8. Copy ViewVC’s scripts from /path/to/viewvc/bin to /home/user/svn.yourdomain.org.
9. Create a file named .htaccess under the /home/user/svn.yourdomain.org directory with the following contents:

Options +ExecCGI
AddHandler cgi-script .cgi

You are done installing ViewVC. Just access it at svn.yourdomain.org/viewvc.cgi!

Note: If you don’t want everyone to be able to see you files, you will have to configure authenticated access to your subdomain using the Dreamhost panel tool for that purpose.

I really think that’s what we should have in mind when writing code:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. — Donald Knuth