Greetings, and thanks! "Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> I've checked in some changes, fixing several more bugs. > > >>since fixed two of them (a typep problem and a REMF bug) and > >>reduced the number of ansi-test failures to 1725 (mostly > >>from the typep change) and checked in these changes. Should > >>I be updating the debian changelog for this? > >> > > I've been using debian/changelog to document all my changes, so if > > you > > want to do the same that would be great. Typically I make an entry in > > the changelog, and then commit to cvs with the same message the > > modified changelog and the fixed files to which the entry pertains. > > It wasn't clear to me what format I should update that in, > so I didn't. > OK > > > >>I have some more fixes I want to check in. How do you > >>test your changes, beyond running ansi-tests? > >> > > My rough guide is the following: > > 1) CVS head -- must self build and run ansi-tests > > 2) Testing tags -- must do the above and build acl2/nqthm/pc-nqthm > > and pass their regression suites > > > I tested these changes with ansi-tests and make test on ACL2 (2.9.3). > Great! > BTW, I changed the property used for compiler macros from COMPILER-MACRO > to COMPILER-MACRO-PROP. The former should be an exported symbol of the CL > package, and was causing some of the symbol tests to fail (since they're > not allowed to come with any properties whose indicators are external > symbols of the CL package.) > OK -- I'll try to refer the compiler macro stuff to symbols and functions interned in the compiler package (as opposed to si) if you don't mind, just to ease mental organization. > DOCUMENTATION is now returning NIL for documentation type T (vs. throwing > an error). I'm not quite sure how this interacts with the generic > DOCUMENTATION > function. > I've always been a bit confused about this. Will nil suffice, or should we be using type-of to flesh out t? Should the generic function simply override the older version we have under lsp/ in the ansi image, or is this only in case the arguments are compatible with the documnetation methods? > The number of ansi-tests failures is now 1690 out of 21309 tests. > Great! I'm intending to eliminate the subtypep items in BUGS in the near future. I'm hoping Vadim can help with the printer/formatter stuff which comprises quite a lot of the remaining failures. And there are at least three new features which need adding -- fork-based plet on systems supporting fork, compiler macros for sequence function inlining, and replacing the cruft in cmplet used to detect static bindings for autodeclaration with a separate pass of level1 -- this should not only be cleaner, but allow capturing of cases where the assigned type is a subtype of the original type. BTW, to this end your commit to gcl_seq.lsp: + (let ((len (length s))) + (declare (type fixnum len)) + (do ((i 0 (1+ i))) + ((>= i len)) + (setf tail (setf (cdr tail) (cons (elt s i) nil)))))))) len will be automatically declared to type SEQIND, which is basically (integer 0 (ash most-positive-fixnum -3)). You really want a declare on i. I'd like to autodeclare this too, but it would depend on parsing the bounds to i set by the exit condition, and determining that the increment function is monotonic. If you know of good logic here I'd be most interested. (dotimes ...) automatically expands to code which provides several branches of the loop depending upon the value of len -- gcc will then eliminate all but the fast one when len is declared or autodeclared appropriately. Lastly, we need to ensure that 2.7 is at least as fast as 2.6.7, whatever that means :-). Take care, > Paul > > > > _______________________________________________ > Gcl-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
