Table of contents

1. Table of contents
2. Ideal position:
3. Special needs:
4. Education
5. Short-term goals:
6. Completed projects
7. Awards:
8. Computer Skills
   1. Languages:
   2. Tools:
   3. Platforms:

Ideal position:

Computer programming work in Natural Language Processing

Special needs:

A chronic health problem keeps me from spending long periods of time away from the house, so I would expect to telecommute.

My voice is quite weak, so while the occasional short telephone conversation is OK, I prefer to communicate by email.

Education

None. Everything I ever learned, I learned by reading and doing. I don't think I missed out on anything by going that route. As the source code examples below demonstrate, my programming is solid, effective, careful, and clean.

Short-term goals:

Advance the Auton project to v1.0; it is currently at version 0.0

Completed projects

• Version 0.0 of the Auton project, a web-based collaborative reasoning project.

  This project required

  • Perl
  • HTML
  • Apache
  • mod_perl
  • HTML::Mason
  • CGI programming
  • emacs-lisp (Which I wrote testing and development tools in)

• CLISP-init.lsp, an init file for FUF under CLISP.

  FUF is a sophisticated natural language generation program, using functional unification grammar. It requires an init file that redefines cd, load, require, probe-file for each LISP system it works on. No-one had written written this stuff for FUF+CLISP, so I did.

  This project required

  • LISP
  • FUF

• Presto, a dialog builder for Allegro. This project required
  • C
  • DJGPP
  • Shawn Hargreaves' Allegro library.
  • GUI programming, using Allegro
  • The PCCTS compiler-generation suite to parse data files and configuration files

• FolkSong. FolkSong was written as my part of a collabortive net-based effort to build an open-source djgpp/Allegro-based MIDI sequencer. It was to be a base which the others would expand on, but as far as I know only my part ever got finished. This project required knowledge of C++, MIDI, and GUI programming.

  This project required

  • C++
  • DJGPP
  • Shawn Hargreaves' Allegro library.
  • GUI programming, using Allegro

• Assorted Emacs-lisp packages, including:

  • rtest (124 K), a regression-testing package. This package includes many features that make tests easier to write and run, including a powerful pattern-matching facility. It runs in Elisp, and nearly runs in Common Lisp.

    The pattern-matching facility would make a great package on its own. It gives Lisp a missing piece that languages such as Prolog, Haskell, and ML take for granted. It proved very useful in conjunction with testing.

    I bundled pattern and rtest together only because the pattern-matching and the regression testing use each other.

    Also included in the ancillary directory are a number of generally-useful support packages:

    • tehom-cl
    • arrange
    • safe-equal
    • tehom-inflisp
    • local-vars
    • caselet
    • comint-redirect, which is not by me, it's by my brother Peter Breton.

    The rtest project required:

    • emacs
    • HTML
    • Experience with testing code.
    • Ability to work with and build on other people's code.
    • Ability to translate working code across major redesigns.

    A previous version of rtest was called regress.el and was adapted from a package by Wayne Mesard, who gets full credit for initiating the regress/rtest project.

  • tehom-cl, cl extras for Elisp.

  • arrange, arrange and cull lists.

  • encap, encapsulate list-forms.

  • safe-equal, safely compare circular structures.

  • tehom-inflisp, code to automatically interact with an inferior lisp

  • local-vars, Macros to allow just-in-time local variables.

  • caselet, variant cond/case

  • handhold, for building sexps for specific uses. It's like what `customize' does, but it puts the built expression on top of the kill ring for easy yanking into your code.

    This is a very indirect utility: You include it and write widget-forms for it, so that your user needs to do less programming, because handhold "holds their hand" in constructing data of a specific type.

  • tehom-equal.el A structured comparison operator for elisp, like equal and eq but structured to make specific interior comparisons. This is obsolete in favor of rtest's internal functionality.

  • sandbox.el lets you run untrusted code safely.

    However, it's far less than an ideal solution. It's fairly slow, and it has 2 modes: One mode sbx-with-sandbox excludes too many functions, the other sbx-with-excluding-sandbox excludes too few. Feel free to pitch in and help define a better list of safe functions. Here are my dev notes to help.

  • write-subdirs-el.el writes a subdirs.el file, guessing the purposes of directories from file extensions and canonical names.

    It is primarily intended for developers to make their packages easier to install. It is secondarily for users whose developers didn't do that.

    To use it, you should also have new-subdirs-el.el, which is a replacement for site-lisp/subdirs.el. You may also want to look at how-to-use-subdirs-el.txt, which describes in more details what this file is and what it does.

  • tehom-font-lock.el, a few lines of code that make simple font-lock code a lot easier to write. Caveat: Complex font-lock code will be just as hard as ever.

  • rambledocs, a documentation helper. I find that I am far and away most likely to document design decisions when I am looking at my code, the very issue laid out visibly in front of me. That's when I see the issue the clearest, so that's a good time to document it.

    What rambledocs allows me to do is to go directly from an Elisp function to a section of the doc file with the same name. If there isn't already a doc file, rambledocs will start one.

    A typical rambledocs document looks like this. You will need an XML viewer to view it - psgml will do - and these dtds:

    • A simple outline dtd used by rambledocs dtd.
    • The rambledocs dtd.
  • stout A structured outline mode. With the advent of XML and Emacs' psgml, this has become merely a curiosity.
  • lisp-skels.el Skeletons to aid lisp coding
  • tehom-1.el Elisp extensions for gnus' eforms
  • tehom-2.el Elisp extensions for history lists
  • tehom-3.el Routines to save & restore complex elisp objects
  • tehom-4.el A variant completing-read that returns value instead of key
  • tehom-func-args.el Expand almost any known elisp function to a template.
  • tehom-search.el Support sregex.el for searching
  • hbmk.el Code to move Lynx web browser bookmarks around with few keystrokes. At the moment, this is not user-friendly code. It supports my exact work habits, nothing more.

    This project required:

    • Knowledge of HTML
    • Knowledge of how the Lynx web-browser works.
  • tehom-psgml.el Additions to psgml, mostly made to make it easier to use in hbmk and rambledocs.

    If you want to test it, you will need this test file. Some browsers may want to render it, because it's HTML. If your browser does that, just save it as HTML source.

    This project required:

    • Knowledge of XML and SGML
    • The ability to build on other people's tools
  • tehom-psgml-link.el A bare-bones hyperlink system which works with psgml (the emacs SGML/XML mode) between arbitrary local SGML and XML documents. You don't need to have XLL or anything similar.

    This project required

    • emacs
    • psgml
    • Knowledge of XML
  • tehom-psgml-index.el Generate a table-of-contents from HTML page contents.

    If you want to test it, you will need this test file. Some browsers may want to render it, because it's HTML. If your browser does that, just save it as HTML source.

  • tehom-psgml-fold-by-key.el Interactively fold an XML or SGML document by keywords.

    This is useful in conjunction with my outline.dtd, but it will work with any other dtd that uses the "keys" attribute the same way.

    When writing an XML or SGML document, using a dtd that supports keywords, you can add keywords describing what its part talk about. (That's always been part of psgml)

    Then you can interactively hide or show sections of the document according to keywords. They don't have to be contiguous or in any special relation to each other, and you don't have to find them manually. This package finds them according to keywords.

    This allows you to focus on the sections that interest you at the moment, without worrying about where you put them.

    This code requires the current versions of arrange and tehom-psgml .

  • buff-menu.el.diff (Diffs) Use view-mode from *Buffer list*.
  • rlpic.el

    Minor enhancements to picture-mode for editing map files for roguelike games, especially Omega.

    This project required

    • emacs
    • Ability to work with and build on other people's code.
    • The vision to build proper support tools for a larger project.
  • GEOS-vote.el

    This package is specific to the GEOS site. It allows emacs/gnus users to answer GEOS ballots in a few keystrokes.

    This is obsolete now that GEOS no longer sends email ballots.

    This project required

    • emacs
  • spoiler-space.el A tiny package that works with Gnus to insert proper spoiler space (a courtesy in many Usenet TV groups) with 1 keystroke. This code requires emacs and Gnus.
  • duke-bat.el A few functions to help Duke Nukem map writers who like the style of updating the directory with bat files.

• Elisp documentation, especially skel-recipe.txt, a tutorial on how to use skeleton.el

  This project required

  • Ability to write good, clear docs.
  • emacs
• moveto.tar.gz

  This is a patch for Angband and its variants which adds the ability to move around the map more easily. See the documentation for a detailed explanation.

  This project required

  • C
  • Use of various C development tools, especially make and diff.
  • User interface design.
  • Ability to work with and build on other people's code.
• sformat_as_lisp

  This is a little package to format prolog structures, like [a,b,[C,d]] as Lisp structures, like (a b (C d)) for interfacing prolog and Lisp.

  This works under SWI prolog and will probably work with Quintus prolog. It will probably not work under any strictly Edinburgh prolog, because it uses sformat, not swritef.

  This project required

  • knowledge of Prolog
  • knowledge of Lisp

• Twotris C++ Tetris variant, blocks fall from 2 directions. (Very old. On disk if I still have it)

  This project required

  • C++
  • GUI programming, using LVS Windows

• Contributor to Shawn Hargreaves' Allegro library. Allegro was originally Shawn's project alone, but because of its high quality and open source it has attracted many collaborators including myself.

• Contributor to emacs 20.4.? I added code to allow emacs to read self-referencing structures, using the Lisp reader notations #N=... and #N#, where N is a whole number.
• On a more fun note, I have also written two Duke Nukem levels, floater and Green's Harbor
  With his permission, I also made a bugfixed version of Steve Long's first Duke3d episode.

Awards:

Computer Skills

Languages:

I have coded projects using

• C
• C++
• Emacs-lisp
• Common Lisp
• HTML
• Perl
• Prolog
• XML (assorted DTD's for organizing my text files)
• assorted minor languages (Salt, csh, .BAT, others)

I am also familiar with, but have not used for significant projects:

• Java
• Assembler (both Intel and AT&T syntax)
• XLisp (David Betz'experimental lisp)
• Haskell
• SML
• Scheme

Tools:

• PCCTS compiler-generation suite
• gcc (preferred)
• Borland C++ (not preferred)
• DJGPP development environment
• Allegro library for DJGPP
• Emacs
• CLISP
• FUF
• UMB-Scheme
• HTML-Mason (A web authoring tool)
• CGI.pm
• The Apache webserver
• mod_perl
• SWI prolog
• SML-NJ

Platforms:

• DOS
• Linux
• Have been known to tolerate MS Windows for brief periods.