bryan-openmcl at lunch.org
Fri Jan 7 14:45:42 PST 2005
i was afraid of that. the low-level stuff and bootstrapping process
is still one big black box to me.
a quick hack might be to add a script to the build process that grabs
the docstrings from the source, creates a lisp file full of (setf
documentation) forms and then loads it before dumping.
one could even add more info to the docstring for autodoc generation.
(more useful for the non-"common-lisp-user" symbols)
i haven't looked at how ccl:arglist works, but perhaps a more
def could also be generated from the docstring.
i wouldn't feel so bad about doing it this way (instead of hacking the
fasl file loader) if it added extra functionality.
> The tricky part (if I remember the issues correctly) is getting
> doc strings for the stuff in the level-0/directory to work. The
> FASL files in that directory are "loaded" into a pseudo-memory
> image in a running lisp (via XLOAD-LEVEL-0), and a tweaked verion
> of the fasloader tries to emulate the effect of loading the fasl
> files on that artificial memory image. If doc strings were stored
> in a hash table (as they are later on in the loading sequence),
> XLOAD-LEVEL-0 would have to be taught how to build an initialized
> hash table into the bootstrapping image. (Not impossible, but
> the chicken-and-egg excuse is "but there aren't any doc strings
> in level-0." Of course there aren't: there's no support for them
> in XLOAD-LEVEL-0 ...)
More information about the Openmcl-devel