DBE becomes EBE

I noticed that the console window in dbe did a fairly nice job of editing and after a little more tinkering I decided to bite the bullet yet again.  With a crude editor the debugger can perform a fairly good job as an integrated development environment.  I liked the name dbe, but that seems too much like a debugger.

The name which appealed to me was "ebe".  I suppose it most commonly refers to an "extraterrestrial biological entity", but I wouldn't let that stop.  It's easy to pronounce and it's catchy.  It could have a nice icon for people to click on.  But what should be the official reason for the 3 letters?

DBE Debugger Version 0.1

I have completed the first version of the dbe debugger.  I liked the name dbe - "db" is obviously for debug and I just like the final "e".  I will claim it stands for education, since its main purpose is to assist in teaching assembly language.

The debugger and the documentation are available at http://rayseyfarth.com/dbe.  The index page there is quite plain, but the user documentation is a decent looking LaTeX document converted to html using htlatex.

There are a few nice tweaks added to the first version which I had not considered before-hand.  First it is possible to mark a variable name in the source code window and add it to the displayed variables in the data window.  The program will determine the address using gdb.  Second the user can mark an address in the register window or the data window and easily create user-defined variable with that address.  These features will help a lot.

Started a new debugger

I recently decided that I had spent too much time trying to cope with the problems involved with using various IDE's and debuggers.  I had good success with ddd though it would have been nicer is my pygtk dialog would have added a variable to the ddd data window.  Then I started experimenting with Windows.
I found python along with 64 bit versions of gcc and gdb for windows.  The gdb did not have an internal python interpreter.  So I decided to bite the bullet.

Fluxbox rules!

I have gotten sick of taskbars.  You can autohide them and get pretty much complete use of all your screen space, but, no matter where you hide them - bottom, top, left or right, they will get in your way.  So I have tried quite a few window managers recently.  After much struggle with gnome, kde, xfce, blackbox, etc. I have come back several times to fluxbox.  I like the fact that you can set keyboard and mouse short-cuts in ~/.fluxbox/keys.  I have it set so that I can start nearly all the programs I normally want to run with no menu system at all.

So I've gone one step further, I have made the taskbar invisible.  I can bring up the fluxbox root menu using the windows-key with a right mouse click.  So I can always get to a menu without wasting screen space.  The biggest drawback I have noticed is the lack of a windows list in the taskbar.  Still I can use alt-tab to move through the windows rapidly enough when the window I want isn't visible. The next problem is not having a desktop switcher app in the toolbar.  I can move through the desktops using alt-ctrl and the arrow keys, so this is not hard at all to do without.

So, after much struggle, I have settled on a minimal interface.  Not one pixel is wasted on a toolbar.  No toolbar jumps over my applications no matter where I move the mouse.  I can immediately get to the menu at any point to try to find one of the infrequently-used programs on my system.

There is no need for any more window manager development.  I was frustrated by the Ubuntu switch to Unity, but the net result is that I will probably stick with fluxbox and ignore all the nonsense with all the window managers which change yearly apparently just to confuse the users.

Did I mention that fluxbox is immediately ready when I finish entering my password?  Take that, KDE!  No more Unity with its confusing almost-menu system.  Who needs that junk?  Taskbars are a wicked Windows invention!

Python commands added to gdb

I have managed to define several useful commands for gdb using python.  These commands work with both gdb and ddd.  The basic commands are text commands, but I did manage to create a gtk window for defining variables and watches.

Defining variables

The first command is "dv" which stands for define variable.  The basic idea is to associate a name with an address which can be either a scalar or an array.  Here is the command usage

    dv name address format size count

Python - the little language that can

This week I discovered that the gdb debugger has a built-in python interpreter.  You can issue python commands from the gdb command line using the "python" or "py" prefix.  In the simplest form

     py print "Hello World"

will print "Hello World" using python from within gdb.  But there is much more.

First it is possible to define commands which can be executed directly by gdb.  In my case I initially defined 2 commands "dv" and "pv" which allow defining a variable based on its address with "dv" and printing the variable using "pv".  Then I moved on to defining a command "wv" which will print a variable after every execution step.