[armedbear-devel] Autoloading && method definitions

[Erik Huelsmann]

Hi all,


Today I've been playing around with ways to automatically extract symbols
from our build to automate (most) of the autoloads.lisp maintenance. So,
I've created a small adjustment to COMPILE-FILE which saves the top-level
DEFUNs, DEFMETHODs and DEFGENERICs which have been compiled.

The result is interesting even in light of today's file: analysis shows we
have several generic functions for which methods have been defined across
multiple files. An example: we have definitions for PRINT-OBJECT in
print-object.lisp, but also in java.lisp and format.lisp. This is a
problem, because the autoloader has been instructed to load
"print-object.lisp" only, when finding references to the print-object
generic function.

My conclusion so far is that we need to be able to trigger auto-loading of
more than one source file *and* that we need a way to determine in which
order to load them: we'd typically want to load the file containing the
DEFGENERIC before we load the one with the other method definitions. While
the former isn't trivial (think threading) but doable, I'm still thinking
how to achieve the latter.


So, why do we want autoloading at all? Well, we want to make sure we get a
short start up time and to achieve that, we don't load the parts of the
system that we don't need. How much extra time it would take to load the
full system? I have no idea at this moment. (But we could experiment and
code to that extent would be greatly appreciated!)

And why do I want to part with our current system? Well, from analysis of
the DEFUN/DEFGENERIC/DEFMETHOD data (and thus excluding the DEFMACRO data)
we have 2512 definitions each of which may be referenced by our users.
Currently we define a subset "likely to be used" which causes autoloading
to happen. However, since we regularly break that subset ourselves, I want
to automate the task by collecting the symbols during the build (and allow
for manual additions and deletions - which should be much more rare).


Any comments, complementing experiments or proposed solutions are very
welcome!


Bye,


Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120730/cff50d8f/attachment.html>