Re: Package initialisation in CL boot

[Charles Turner <chturne at gmail dot com>]

On 05/07/2012, Charles Turner <chturne@gmail.com> wrote:
> My current problem is that I'm doing the following for each standard
> symbol in the initLisp method of CommonLisp (it's better abstracted in
> methods, this is just to show the idea)
>
> Symbol s = Symbol.make(LispPackage.CLNamespace, "CAR");
> LispPackage.CLNamespace.exported.add(s, s.hashCode());
>
> and so on. ADD is calling AbstractHashTable#put to place the name.
> However, when I intern 'car from LispReader, it doesn't find the name,
> despite it looking in the correct package's exported symbol table.
> This time INTERN calls the Namespace#lookup method, which appears to
> be searching the same data structure as PUT. So CAR was defined as
> above in the CL package, and I start lisp in the CL-USER package. I've
> traced the execution path in the debugger, it correctly finds the CL
> package in CL-USER's import list, but for some reason the symbols are
> not CL's external table now...

I'm starting to suspect that the String<->Symbol mappings I'm
populating in initLisp are getting garbage collected by the time the
defun(..) bits are happening in initLisp. The loadClass and
importLocation stuff was happening before the defun bits, so I can
only surmise they were somehow trashing CL external symbol table.
Placing my standard package population code right before the DEFUN's
solved the problem, and I get the behaviour I expect. This isn't
completely satisfing not knowing what happened. Is it feasible that
because of the weak references in AbstractHashTable, they were getting
collected somehow? Anyway, my standard CL definitions are working, no
I just need stop the compiler saying things like "No declaration seen
for {COMMON-LISP-USER}:+ and instead retry such failed lookups in the
default namespace...

Charlie.