[Posting reply to mailing list so our conversation gets archived for posterity.]

On Mar 30, 2019, at 05:10, Don Cohen don-abcl@isis.cs3-inc.com wrote:

Mark Evenson writes:

...

It took a little while to approach the AP5 code, but I managed to hack together the attached patch for ABCL which allows the AP5 build strategy to succeed.

[…]

...

The attached patch contains a provisional hack to the ABCL compiler which computes the alist form from the vector form rather than signalling an error, so in order to use ABCL with AP5, you will have to build ABCL from source.

Thank you!

But is there any reason it won't suffice to simply redefine this function in a running image before compiling?

Patching the compiler in the running image will work just fine.

...

To truly fix this one would have to understand the AP5 compilation strategy better, and then probably adjust the compiler's use of specials.

I think I understand the compilation strategy - it's not that complicated. But I don't see what that has to do with this problem. The patch suggests that the real question is how *fasl-uninterned-symbols* got to be a vector in the first place. Would it help if I avoided uninterned symbols? Replace calls to gensym with gentemp?

The reason I suspect AP5’s "compilation strategy” (more like “need for recompiling and loading as it goes”) is twofold:

1) In my attempt at reproduction of the problem, I encountered no problems with a toy fasl containing references to uninterned symbols with any combination of CL:LOAD and CL:COMPILE-FILE. Absence of evidence is not evidence of absence and all that, but the ABCL compiler works with many systems in Quicklisp defined using ASDF without problems.

2) From the stack trace, it seems clear that the error stems from the compiler being invoked (see ’59:’ ff.) in the process of the loading the fasl itself (’70:’ ff.):

[…] 57: (JVM::SERIALIZE-OBJECT (#:A77910 #:A77911)) 58: (JVM::EMIT-CONSTRUCTOR-LAMBDA-LIST (#:A77910 #:A77911)) 59: (COMPILE AP5::|Test-RELADDER| (LAMBDA (#:A77910 #:A77911) (AP5:WITHREADACCESS (LET ((#:G77912 #:A77910) (#:G77913 #:A77911)) (LET ((AP5::CXVALUE (AP5::VALUEINCURRENTCX (AP5:THEAP5RELATION AP5:RELADDER) #:G77912 #:G77913))) (COND ((NOT (EQ AP5::CXVALUE 'AP5::INHERIT)) AP5::CXVALUE) (T (NOT (NOT ((LAMBDA (AP5::REL &REST AP5::TUPLE) (AP5::FMEMB3 AP5::TUPLE (AP5::GETBASEDATA AP5::REL) ))))))))))))

[…]

64: (AP5::NEED-TESTER ) 65: (AP5::GET-UPDATE-SOURCE T ) 66: (AP5::GET-UPDATE T ) 67: (#<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {6992BE4}> {6992BE4}>) 68: (FUNCALL #<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {6992BE4}> {6992BE4}>) 69: (SYSTEM:INIT-FASL :VERSION 43) 70: (SYSTEM::%LOAD #P"/Users/evenson/work/ap5/bin-abcl1.5.0-MT/relation.fas" T NIL T :DEFAULT) 71: (LOAD #P"/Users/evenson/work/ap5/bin-abcl1.5.0-MT/relation.fas”)

ABCL fasls are zip files that contain two things: a loader consisting of CL source forms, and JVM classes emitted by the compiler. In loading, the loader forms are interpreted which make the necessary modifications to the environment as well as loading the compiled JVM classes. Each JVM class emitted by the compiler has a piece of initialization code (known in the JVM as static initializers) which performs additional housekeeping in the environment. In the above stack trace, the INIT-FASL call at ’69:’ is evaluating the forms in the loader.

The loading of the JVM class which is causing the stack trace which seemingly corresponds to the error is on line 392 of “relation.lsp”, namely the line which adds a tester:

(++ RelTester 'StructProp ‘StructPropTester)

But I can’t “seemingly" figure out how this line expands into the call to AP5::GETUPDATE, so maybe my reasoning is somehow faulty here, but I at least wanted to record how far I have gotten.

The only strategy I can currently suggest for AP5 which might be friendlier to ABCL is to not invoke CL:COMPILE at fasl load time if this is indeed what is occuring. Maybe I can craft a simple example to test that theory.

Off to pack and travel to the European Lisp Symposium,

Mark