Go to the first
section, table of contents
I've been responsible for three main packages at the
- Knowledge Manager
This is a NeXT-specific hack written by Kraig Eno
which I inherited. It is actively used by Jose
and Cornelius at present, but slow and probably
should be rewritten rather than extensively
modified: It was written as a quick-and-dirty
prototype. My canonical source for the Knowledge
Manager is in scala:jsp/KnowledgeManager/*.
Scott Bradley has made major progress toward
replicating the KnowledgeManager functionality
using msql and Java: Pursuing that code would
probably make more sense than making major
changes to the NeXT version.
Skandha3 is mostly used by John Sundsten at this point.
It is very stable; For the last few years the only
changes I've been making really are to add support
in the Skandha3 file format for information used by
the Skandha4 emulator in slisp for Skandha3, such
as texture-map coordinates. I maintain Skandha3
in ~jsp/iii/*; I've left an up-to-date copy of
this tree in /usr/local/src/skandha3.
Skandha3 still does many things the Skandha4 emulator
for it doesn't do, most notably 2-D section editing
and surface tiling. It is also faster and more resource
efficient. On the downside, it is nonprogrammable and
very hardwired for serial section data displayed in
Skandha4 is a completely different program from
Skandha3, based on a free version of the xlisp
lisp interpreter plus maybe 50,000 lines of
added code implementing 3D graphics-based
classes and widgets. Very flexible, lots of
potential which is just beginning to be used.
I do Skandha4 development in the betz:~jsp/src/slisp/*
file hierarchy; I've left an up-to-date archival
version of the code in /usr/local/src/slisp/*.
Skandha4 is host for several applications written
in slisp, which I lump in as being part of Skandha4
for most purposes. These include
Various other experiments and minor utilities are
floating around the Skandha4 sourcecode, including
src/slisp/xmri/lsp/xskandha4.lsp, which is intended
to grow into a native-mode application allowing
interactive access to most of the power of Skandha4,
including in particular the ability to interactively
apply the pointwise operators to graphic relations:
This could result in sort of a visual APL, with just
a little work.
The Skandha3 emulator for Skandha4. Fairly complete,
does some nice things like texture-mapping which
Skandha3 proper does not do, but very untested and
consequently a bit flaky. Tucked in a submenu of
the Skandha3 emulator is Skandha Morpho, an onscreen digitizing
subapplication which has been used quite a bit
by John Sundsten: Most of the application code
is in src/slisp/xsk3/lsp/xmorpho.lsp
The brain mapper application for the brain project.
The mapper is actually a subapplication in this
program, which also attempts to combine orthogonally
the ability to view 1-3 datasets each with 1-3 windows
in several different imaging modalities. I'm not
very happy with the result: The attempt to factor
the code so many different directions at once makes
the program very hard to understand and maintain.
There's lots of good code in this application, but
if nontrivial changes are contemplated, I'd advise
making a copy of the program and stripping out all
unwanted parts and then simplifying to produce
something easier to read and maintain, or else
starting a new, specialized application from
scratch, stealing code and ideas liberally from
the existing program. Note in particular the
mapper submenu demonstrating marching-cube
A small but important Perl hack which we use to
download datasets from the MRI machine. In practice
the source lives in /usr/local/bin/fetch-patient.
The GUI part of this application is driven by Gustaf
Neuman's excellent WAFE toolkit, a Tcl-driven X
Windows toolkit. He's constantly improving and
extending it; Good projects would include downloading
and installing a newer version, and converting xfetch-patient
from using the Athena widget set version to using the Motif
widget set version, which would look much nicer and fit in
better with the SGI window system. There's still some
junk code floating around fetch-patient, left over
from my building it by adapting an existing application,
but I think it is reasonably well commented internally.
There are still some glitches in the per-frame information
gathering part of the app which I haven't figured out
yet; Other than that, it seems to work pretty well
most of the time. Being an asynchronous app driving
an undocumented commandline program at the far end,
it does tend to fail now and then, however.
Go to the first
section, table of contents