ACL 5

After much experimentation, I figured out how to build a LISP image (application) in ACL5.  The problem is that the new image-building machinery does not inherit anything from the running image.  The solution is to build a project that contains a single file that loads your system.  For example, here is the file I used:

(cl:in-package "CL-USER")
(load "t:\\dev5\\fsl\\base\\lportabl.fasl")
(let ((p:*module-defaults* '(#p"t:\\dev5\\fsl\\" #p"t:\\dev5\\src\\util\\")))
   (p:require "scaffold/query.l")
   (tquery :ipl-well)
   (p:require "x-dm/impl")
   (p:require "x-dm-sql/impl")
   (p:require "x-ppdm/impl")
   (p:require "x-uwi/impl")
   (p:require "mdl-ipl-well/xmain")
   )

Another wrinkle is that the initial function for the image must return a window.  The image will run until that window closes.  We will probably have to work around this behaviour.  Maybe we can return NIL or a closed window.

In the course of troubleshooting this process, I noticed that the query tool was still using some of the compatibility classes in the ACLWIN302 package.  We should delete this package when developing.

During the ACL 5 port, I discovered that there was a change in the behaviour of format with respect to symbols.  For example, (format nil "~A" 'x) will not return "x" whereas the old Allegro returned "X".   This wouldn't matter much except that some of our macros will generate symbol names using the formula and therefore would generate mixed-case names.  I think that I have found and fixed all such cases.

I implemented the ACTIVESCP package, which allows LISP to invoke scripts through Microsoft's ActiveScript machinery.

Java 2 has a bug, specifically Java Bug Parade #4172371, which we hit from time-to-time.  Specifically, the VM signals a VerifyError if an inner class method calls a private outer class method as its only action.

We discovered a restriction in JDBC today.  The JDBC spec states that when reading columns from a row in a result set, the rows must be read left-to-right and no rows may be read twice.  The spec says that this restriction is for compatibility for some underlying databases.  Presumably, this restriction is in place so that a driver may use a stream to retrieve results, which makes a lot of sense when there is a prospect of BLOBs etc. in the result set.  This problem surfaced when Larry was processing metadata result sets from SQLServer.