\providecommand{\sticky}[1]{\marginpar{\tiny \tt #1}}

Document Directory Structure

Maybe we want to call all directories:

Interesting how names have to grow (here 5 letter words) when things become more important.

In that fashion we can order the chapters (e.g. the various chapters could be printed with "lpr */" and would print in the correct order). That can be helpful when downloading a tar file.

so here is how we can have a flexible naming scheme that allows us a reasonably flexible, albeit clear electronic document structure, and a semi-automatic integration of new directories.

All chapters are listed by relative path in a file in the adm directory. Every chapter contains a paper.tex and a makefile for local commands such as burn, build, clean, view, read etc. I call this a toc list (table of contents).

A perl script (makeDocList -p) makes a file that lists all directories (relative path) that fit a simple description in a file (e.g. all files in a lower case directory tree that contain a paper.tex file). Another script (testToc) compares all these files with files listed in the toc list.

The same script (makeDocList -m) finds all lower case files that contain a makefile and java files. This list will be used for mkae test and make compile. Maybe a third perl script (testToc) could check that all paper.tex directories contain such a makefile.

Great, this flexible scheme of perl scripts and file listings will allow us partial burns and builds, compiles and tests (firewalling the results). The order is determined in the toc file.

Let's get to it!!

Every book has chapters. Every chapter has figure directories (that compute the figures), a paper directory that contains the paper.tex file and its derivatives (maybe things such as paper\_html/ or paper\_idvi/ should be neighboring directories, maybe that paper directory should be capitalized Paper .. easy to keep apart, but impractical for small papers, maybe all finished paper versions should go into a capitalized Paper directory.), a Fig directory where I drop the computed figures, and a Data directory where I keep the data. The Data and Fig directories are links to disk that is not backed up frequently. The rational is that the input data does not change from day to day and that the figures are reproducible. (If the figures are not reproducible you probably want to keep a back up). I keep a common Fig and Data directory for each paper. I could keep them separate for each figure directory (maybe more object oriented). But I see the chapter-paper as my smallest publication unit currently. Makes me keep it short.

The chapter directory name should be related to a problem (coherency cube), the individual figure directories should be related to a method on how to approach that problem. The naming scheme helps me to focus on problems rather then methods.

By the way, I would prefer dash over underscore to build my paper directory names. The underscore is a special character in \TeX. \sticky{Bill Symes supports that}

How to organize our classes

certain directory names and places are forced upon us by java standards (.e.g. net/www/content )

other directory structures we can choose freely.

Here is what I suggest: Jag as a book!

I suggest a simple naming scheme for the various chapters: eg c1conv c2deconv c3zmig c4dmo The c? will always print things in a specific order (important when sending things to "lpr" but at the same time we allow short descriptions of the context. With this TeX, LaTeX2html etc can make the Table-of-Contents page all by themselves.)

abstract: jag: operator, vector, solver, util (dotproductTest)

concrete: rsf vectors: rsf operators: kmig, conv, deconv rsf solvers: CGsolve rsf tools: Spike, Attribute (Stats), ToString (Disfil), Patch (also an operator)

(Note: all operators are currently in their own package. That is good as long as they are research objects. should they become routine objects they move to a single big location. that allows us to include all routine operators with single import statement. same is true for other related object groups that naturally want to be in a single package.)

isf (soon)

io: sepio


Graphics renderer: (Ken's stuff)

Graphics language: (such as vplot. is that needed within Java?)

xtpWeb representation

database solutions (?)

Java seems to embrace the idea of putting class files into separate, parallel directories to original java . javadoc throws all their files into a single directory. what do we want to embrace? we probably should embrace their solutions until we are really disgusted.

We may want to distinguish things code which will not change (in the sense of having newer versions) with that which is still "in the works". We would have a SEPcore.

Joel: One directory structure:

jag rsf isf ... v o s v o v o

(v = vector, o = operator, s = solver) Note: most vector types will not have special solvers. Also, you can see all the vector types at the top level.

Another structure possibility:

jag vector operator solver v o s isf rsf ... isf rsf ... as necessary (if at all)


every directory carries its own tests (oo style) from top you can descend and find no paper.tex files until a certain level: there you find a paper.tex file (and a Fig dir etc). There will be no paper.tex files below that level.

As things mature, I expect paper.tex level to be 1 level below root, just as in Jon books. there will be another level of dirs below that are responsible for making the various figures. compromise: paper.tex local and object oriented, easy crossreferencing within a paper.tex file.

paper.tex file is root file; other doc versions are derived from it.

The programs can have a main method that allows it to be used in a standalone fashion or in an integrated class. We write additional Test routines so that we do not burden the actual routines with the Test part. A two-door situation: first door for object-oriented programms, the second door for standalone programms.

dirstructure once more

This is probably useless and better formulated in one of my sac articles.

This Makefile is the chapter Makefile. It maintains the text, pictures and programs of this chapter.

The rules in this Makefile:

Administration and reproducibility

I would like to have all my shells replaced by java files. That would be nice, wouldn't it? A total burn across the net.

when should a file be in tex format: all of them? then some of them translate into ugly html format

Can I have a few html formatted file (e.g. todo.html or index.html) which I can then translate to tex with a simple script? use html2latex.sed (in matt/usr/src/)

what do we want to keep in html? especially things with hyperlinks overviews that change rather rapidly ... nothing scientific that needs formula editing.