--text follows this line--

The version of ap5 from 2009 supposedly was able to build in the abcl of that time. I'm now trying to make a more recent ap5 (but not very much changed) build in current abcl. I've put the current source at http://ap5.com/ under ap5-2019.zip so that others who are willing to help can reproduce the problem. Unfortunately I don't have a small example, only a large one.

If you retrieve and unzip the source, you'll find a file abcl-build.lsp which I'm trying to get to build ap5. In order to use it you have to change this line: (defvar *top* "/tmp1/ap5-2017/") to be the directory where you've put the ap5 source subdirectory. That is, the file /whatever/source/abcl-build.lsp should contain (defvar *top* "/whatever/")

I then do the following: java -jar abcl-bin-1.5.0/abcl.jar then load that file - in my case (load "/tmp1/ap5-2017/source/abcl-build.lisp")

This ends with the following error:

Error loading /home/tmp1/ap5-2017/bin-abcl1.5.0-MT/relation.fas at line 210 (offset 12978) #<THREAD "interpreter" {5E5D5718}>: Debugger invoked on condition of type TYPE-ERROR The value #(#:A63056 #:G63088 #:A63337 #:A63338 #:A63324 #:A63325 #:G63450 #:G63451 #:A63559 #:A63560 #:A63546 #:A63547 #:G63674 #:G63675 #:A63797 #:A63798 #:G63898 #:G63899 #:A64007 #:A64008 #:G64039 #:G64040 #:A64134 #:G64160 #:G64256 #:G64356 #:G64357 #:G64454 #:A64602 #:G64628 #:WHOLE-65572 #:ENVIRONMENT-65573) is not of type LIST. Restarts: 0: TOP-LEVEL Return to top level. [1] AP5(2): :bt

0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {16575712}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 4: org.armedbear.lisp.LispObject.car(LispObject.java:161) 5: org.armedbear.lisp.assql.execute(assql.java:51) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:832) [1] AP5(3):

It's difficult for me to figure out what's causing the error since I don't know much about interpreting java compiler output. However I hope a little background and some experimental evidence will help. First, the build process loads certain files before it compiles them and then later attempts to load the compiled versions. The error is coming from trying to load the compiled version of the first of these, relations.lsp. The build process actually loads and compiles several files before it tries to load the compiled versions, but in order to reproduce the error it's enough to load relations.lsp, compile it, then try to load the compiled version. In order to figure out which form in the file was causing the problem I tried a number of initial subsets of the relations.lsp file and found that if I stop at line 836, after : (++ reldeleter (relationp 'relation) '(lambda (&rest ignore) (declare (ignore ignore)) 'deleterel)) I can - load relations.lsp (I do this in order to return to a state that does not depend on the part of the compiled file that was loaded) - compile the initial segment - load the compiled version of the initial segment without error. However if I add the next form, (defun deleterel (ignore rel) (declare (ignore ignore)) (loop for a s.t. (relationarity rel a) do (-- relationarity rel a)) (insist "supposed to delete it" not (relation rel)))

the load of the compiled file generates an error similar to above: Error loading /tmp/test1.abcl at line 198 (offset 11994) #<THREAD "interpreter" {2040734F}>: Debugger invoked on condition of type TYPE-ERROR The value #(#:G292048) is not of type LIST.

On the other hand, if I put the defun deleterel into a separate file, I can - load relations.lsp - compile the initial segment ending with ++ reldeleter - load the compiled version of the initial segment - compile the file containing defun deleterel - load that file without error.

The fact that the error from this test contains what appears to be a vector of only one object whereas the original contains a longer vector suggests to me that the compiler is combining multiple forms into a vector, and the defun deleterel is just the first one. Of course that doesn't explain why some other code expects a list instead of a vector. I'm hoping that someone will know immediately what causes the error I'm seeing and what I can do to avoid it.

This reminded me of something -- you might notice in the file relations.lsp and other files the following incantation: (buffer-break) which is defined in sys-depe.lsp:

; The purpose of buffer-break is to prevent compile-file from ; putting two forms together when the first one has to be evaluated ; before the second can successfully read, e.g., if the first defines ; relation R and the second contains something like #,(relationp R).

#+(or lispworks (and lucid sparc)) (defmacro buffer-break () '(eval-when (:load-toplevel :execute) nil))

#-(or lispworks (and lucid sparc)) (defmacro buffer-break () nil)

If I change the first of those forms to #+(or abcl lispworks (and lucid sparc)) I still get the same error at the same place, but I wonder whether the underlying problem is similar to the one that caused buffer-break to be invented.