Coen’s blog

A long time ago, when I still was in high school, I sometimes tried to cheat my way out of some classes (like French, for instance). Of course, after a while, I got reasonably good at it, and that’s basically how I finished the course. I became more and more bold in other courses too, and after a while I got caught ( that was inevitable, of course).

Some time after I finished the part of high school we call ‘brugklas’, I came across a teacher who, to my surprise, encouraged using cheating notes. As I soon would realise, the man ment for us to create cheating notes before the exam, and not use them during one. That way, he said, you learn to summarize the things you need to study for that exam, and you’ll remember it, too.

The man was right. So, now that’s all behind me, I can use this story to do some cheating, while pretending to learn from it as well The cheating is about a trivia channel on irc. I’m writing a bot in Java that can parse irssi logfiles, and is also able to learn from the questions the trivia bot asks. The things I’m hoping to learn from this: How to simulate a human being that answers the questions (that means, among other things: do not answer every question correctly, but also that is makes some sense), and what is the nicest, most efficient way to learn questions; how do I determine the correct way to answer, etc.

So: $learning_by_cheating++

2 Comments »

For some time now, I have been working om my messaging client Skaar. Last week I built a version that only can connect to an IRC-server. There’s still a lot of work to do, but it was time to test and debug my work done so far.

A classmate told me to use valgrind to test Skaar for memory leaks. Valgrind is a suite of tools for debugging and profiling programs, so that should work, and there I went:

valgrind --log-file=./valgrind.log --leak-check=full ./skaar

After shutting down, it turned out that Skaar had left something behind, and not that modest (43Kb) either. It’s actually not that simple to prevent memory leaks, I learned. The obvious cases seem to scream: free(3) or delete me, but the not so obvious cases keep their mouths perfectly shut..

Obvious case:
char* line = (char*)malloc(513);
memset(line, 0, 513);
strcpy(line, "PRIVMSG #mychannel :foo\r\n");
...
free(line);

Not so obvious case:
// in RFC1459.cpp
JoinMessage* joinmessage = new JoinMessage(this, line);
return (AbstractMessage*)joinmessage;

// somewhat later in Skaar.cpp
AbstractMessage* message = protocol->translateIncoming(rawmsg);
...
delete message;


I’m wondering if this is the right way to end the AbstractMessage*‘s life, by the way. Who’s responsibility is it to get rid of the message? I could go with this solution, that says: “Here is your object, have fun”. I could also create a function in the protocol that destroys the message, something like RFC1459::destroyMessage(AbstractMessage* message), that says “Here is your object, but you have to let me take care of it’s end. Actually, I have no clue which one is the best choice, if there is a best choice here..

But, back to business: all I have to do now is just test every possibility to see if there are any leaks. Or I could just watch it when I write code, which also sounds nice.
Another tool that I’ve come to value is gdb, The GNU Project Debugger. This tool allows you to see what happens ‘inside’ the program while it executes. And yes, I stole that line from gnu.org
To start using gdb is not very hard, just type gdb yourprogram, and that’s that. To actually start executing you program, type run once gdb has started.

No Comments »