Large portions of the week were devoted to learning the ins and outs of hiredis and its limitations. I spent so much time deep in the bowels of the library that it’s the things I learned about it are too domain specific to warrant mentioning here.
Anyways, onto the learnings!
- SDTimes.com is really full of shill-articles, even moreso than TechCrunch which I will credit with occasionally breaking actual news.
- Using Valgrind during (C) development can be invaluable for spotting memory corruption issues early on. There are some cases where memory corruption will not result in a
SIGSEGVbecause the program hasn’t tried to read or access the corrupted memory yet, but Valgrind will catch these invalid accesses for you.
Fileoperations in Ruby 1.8 are interpreter-blocking, even when using Ruby 1.8’s sad excuse for “threads” (i.e. they’re really green-threads). This means if you’re performing a large file operation in Ruby 1.8 it will block your entire interpreter. The only fix for this problem is to use JRuby or Ruby 1.9 which actually introduces native threading calls.
gdballows for running a series of
gdbcommands when the debugger starts up with your program. This is useful while developing to always run your program through
gdb. For example, a simple file with
set args foo bar bazand
runcan make life much easier for re-running your program over-and-over while debugging.