[Axiom-developer] Re: cvs

[root]

re: commit. 

great. I'll download and test it.
In general I've learned not to mention to anyone that I've
changed CVS until I've uploaded, downloaded a brand-new copy,
compiled, and tested it. It is a long, painful cycle, no?

re: backout

I think the idea is that when you make a change it becomes 
foo.1.2 and if you want to get the previous version you
explicitly ask for 
cvs -r foo.1.1
I haven't done that explicitly but you're welcome to try it.
CVS maintains the old versions but I don't know of an explicit
command to "back out" a change. Usually you download a prior
version and then check it back in so it becomes foo.1.3

re: daase files

The daase files are random access files.
You get a number, seek into the file that number of bytes, and call read.

The format of the daase files is:

integer-offset-to-index
(sexpr) (sexpr) (sexpr) .... (sexpr)
(index)

The file is read by reading the integer offset,
seeking into the file that many bytes,
and reading the index. The index is a table
of lists of offset numbers (some of the offsets
are immediate data rather than numbers).

So, for instance, in browse.daase you can open the file in emacs,
read the first number (2135125) and then do:
C-u 2135125 C-f 
and you end up position 2135125 characters into the file which is
the start of the index list. If you know what the index list
entries mean then you can look up properties.

One of the subtle parts of some of the files is that there is a
compression algorithm I wrote to minimize the size of the daase
files. It could be the case that the compression algorithm has
a bug. In any case I'm going to write a program to compare two
daase versions. This involves reading the index, walking the index
entries to get the data, and comparing the results from the other file.
I've written a few checking routines of this type before. (see libcheck
in util.lisp.pamphlet which checks INTERP.EXPOSED (which I have to 
rewrite to use exposed.lsp)). I plan to add these checking routines
as part of the build process (they used to be there).

re: conflicts

I deleted some files per requests by David and Camm
and they've been uploaded again. Be sure to do
cvs update 
before you do a 
cvs commit

The "update" makes sure that you have resolved all of
the conflicts before adding your code.

I've forgotten this in the past but so far I've been the
only one making cvs commits. I expect that we'll all be
doing commits in the future so we have to be careful to
do cvs updates first.

Despite the unforseen gaffe I'm quite pleased that you 
went ahead and made independent changes. Provided we all
carefully check our work I'm hoping to see more of this.

Tim