I want gdb to die in a fire. If thats possible.A sentiment I can only agree with, to be honest. However, it remains in its spread of variably buggy obsolete forms embedded within the development tool chains of too much of the world to avoid. Some notes on living in the land of the clone of the Unix tools from the 1980s. A link to a GDB reference card. Programmable systems (debuggers like GDB, editors like emacs, typesetting systems like LaTeX) have been universally dire in user experience, in _my_ experience. The intended bonus of programmability becomes a curse of necessity; the burden is placed on the user to make the tool usable in the first place. In essence, I want to write programs to solve _my_ problems; not to solve problems in the tools I use; and _not_ to write programs in the debugger while debugging the interesting program or to debug program errors in a document processor.
A set of optparse documentation for common tasks since, as it notes,
we start new project so seldom, it is difficult to remember all those recipes that we come up with, every time we add a new command line option. This article is an attempt to bring together such recipes.
Python can query its environment for the functions in the current module (which is done slightly differently than for _other_ modules). This is useful for auto-testing, saving the need to write out a function list explicitly. Can embed these gist things into a blog post, too.
After the GDB rant, I confess I don't program gdb much and have not (yet) needed a .gdbinit file to customise GDB in a semi-permanent manner. However, I have some user defined commands to not forget in case I need to stay in GDB a little longer...
JGrowl implements growl style notifications in a web page. Cool, if not immediately useful. Also, drop shadows via CSS.
Can fork multiple threads (well, processes) in bash and then join (wait) for the completion of them. Good for parallelism of shell script controlled processes.
cmd_A & cmd_B & wait
