Brasstacks

I should mention my non-blog site , which exists pretty much to hold information for recruiters who want to get some idea of my software experience. Don't expect much exciting there. I am, by the way, currently and happily employed, but am interested in opportunities in the New York City metropolitan area.

My blogging has been much less frequent of late, mostly because of an unfortunate abundance of non-computer issues. Despite those, I believe I have made some progress in my Chaosnet-on-OpenMCL work, but I've switched most of my hobby-development to Python, mostly to get in touch with trends outside the Lisp Universe. My current main project circulates around ChaosNET emulation; the main thing going for Python here is a socket interface that is roughly compatible between UNIX-like and Windows operating systems. Lisp can support that as well, but not for my favorite and familiar implementations. (One thing I hope to try before I get through this is to get an asyncore-like framework set up in CLISP.) So far, I have implemented a `chaosd' process in Python that simulates multiple ChaosNET `ethers' in the form of localhost TCP streams (on Windows or UNIX-like) or UNIX-domain sockets (on UNIX-like); each stream corresponds to a subnet. The idea has manifold goals: Allow the...

Python isn't so bad. However, I find myself bothered by a few issues. The development environments are not as Emacs-oriented as Lisp environments are. My default installations of Emacs don't seem to come with Python mode, and I have mixed success doing SLIME-like development on Windows and Linux. For now, I use IDLE. I find it hard to view what is going on in the stepping debugger, including such basics as what line in the code I am currently stopped at, and have no apparent interactive inspection facility. (E.g. if I step through my code, I can see a local variable holds a dictionary, but see no way to expand the view so that I can see every entry in that dictionary, or to see the contents of objects contained in the dictionary.) Backtraces by default are limited in their description of the stack frames (also, Python's documentation (proudly?) states that Python uses the termination model for error-handling, although rumor has it the backtrace stacks include more infor...

In order to better serve those folks Googling "2007FP xorg.conf", I've included an annotated xorg.conf file that seems to work well for me and my Dell 2007FP monitor. I hope it helps you. (It is, naturally, provided "as is", without warranty of any kind, etc., etc., because it could very well damage your hardware, although nowadays monitors are much more forgiving than they once were.) (It seems from my site logs that my venting about my adventures with Linux, xorg.conf, and the 2007FP is one of the more popular Google hits for my site now, just one day after it was posted.)

Time for a "Linux is not ready for the desktop" rant. Some time ago, I picked up a Slackware 10.1 4-disc set. I've been trying to use it on a Dell Precision 610 MT workstation, Xeon Pentium III. (That's what you can read on the label.) Through some struggling through the initial start up screens, I was able to determine the box has two SCSI internal drives. I also have a Dell 2007FP monitor (pretty nice). Getting X to come up in something other than 1024x768 was an ordeal. Perhaps I should have realized that no amount of so-called "handholding" was going to help me, and gone to the xorg.conf man page directly. Silly me, I thought this would be like a normal desktop environment, where I would open something called something like a "control panel" and find a sub-thingy labelled "Display" (KDE buries this under Peripheral) and select the 1600x1200 resolution my display claims to support. No. Only 1024x768 or worse. So I go to slackware...

Clive G. Page 's Professional Programmer's Guide to Fortran 77 is available under the Gnu Free Documentation License. I suppose this means I should dig up my texinfo translation of his LaTeX, which I did a number of years ago, merge in his more recent changes, and release it.

Just wanted to capture a few more thoughts; over the weekend, I experienced what I think was my first case of deadlock. My chaosnet-on-OpenMCL implementation had worked just fine when the two sides of a connection were careful to exchange only one packet at a time, taking turns. When I tried to listen to a SEND (the Lisp machine analogue to an instant message), the CADR emulator sent two packets in quick succession, and my OpenMCL process would freeze trying to receive it. As an aside, I get the feeling that I don't really know how to debug this kind of thing in OpenMCL: looking at backtraces does not always make it completely obvious which semaphore or lock is being waited for in the various threads, and I don't think it is possible to look at semaphores to see which thread(s) are waiting. In any case, I concluded that my somewhat haphazard use of a "count lock" to protect access to packet number information in a connection was either being used recursively, or v...