[xcvb-devel] Next on the TODO list: multiple BUILDs, search paths, etc.

[Geo Carncross]

On Thu, Dec 25, 2008 at 9:22 PM, Attila Lendvai <attila.lendvai at gmail.com>wrote:

> > May I suggest having a xcvb:*find-modules* var (or similar) that contains
> a
> > list of these functions (or
> > symbols to these functions perhaps) so that instead of just adding new
> > pathnames, we can add
> > functions to find lists of these pathnames. They could optionally accept
> a
> > module name in case the searching module can use the information to
> narrow
> > the search better.
>
>
> +1 from here, modulo details, naming, etc.


The naming isn't important to me either. Neither are a lot of the details :)


>
> i've never liked the static *system-registry* with the manual
> symlinking on the filesystem. using a directory scanner yields a much
> pleasing user experience for me. so, please make the functional way
> the default or the first in the docs to advertise it for the
> newcomers...
>

Well, I wasn't thinking about it as something incompatible; I'm talking
about implementing the suggested search system in an extensible way.
Something like this:

(defvar *module-finders* '(find-in-home find-in-environ find-in-sys
find-on-http))
(defun find-in-home (id) "Searches ~/.xcvb/systems for ID" ...)
(defun find-in-environ (id) "Searches $XCVB_SYSTEMS env" ...)
(defun find-in-sys (id) "Searches /usr/lib/xcvb/systems for ID" ...)
(defun find-on-http (id) "Searches various websites for xcvb systems" ...)

Such that it would implement the suggested default path, but specifically
export *module-finders*
so that instead of merely setting *system-registry* (or similar), we can
push something interesting
onto module-finders to do a local (or packaged) search; For example, my
application which ships with its own dependencies might push on a function
which prefers the included files, or when porting an app from sbcl to ecl
(or whatever), I might find i want to change the "home" of some modules on
an ad-hoc basis so I can use an older version of a particular module,
without having to move files around on the disk.

Originally I was thinking the finders would return a list of pathname
objects, and that network-methods would use a cache. This would also make
implementing (modules-apropos) or something, easier.

I've thought more since then:

The finders could return some object that we could interact with using:

(defgeneric finder-get-more-findees (what))
(defgeneric findee-get-definition (found))

Where "what" was returned by one of the functions listed in *module-finders*
(to implement lazy lists- perhaps just a list and a generating function
would be enough...), and "found" is one of the members of "what".

"found" would usually be a pathname (in which case, findee-get-definition
would open, read it, and return the definition), but it could also be other
things- perhaps a network socket or some rows from an sql database.

Once a defintion had been read, xcvb would have to check to make sure it was
actually the desired module; The finders would be able to assume ID was just
a substring to give searching and retrieving a common interface, but by
allowing ID to be T (all systems) we could mirror/cache all systems easily,
or debug the search tree easier.

Of course, this still supports the search path you outlined previously.

Also, if the found object is dynamically dispatched, different module file
formats could be implemented by a special loader, and (more interestingly)
:around methods could be used to dynamically process the defined systems
(instead of having to edit or fork the definition files). I don't know how
valuable this would be to others though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/xcvb-devel/attachments/20081226/8c57fd94/attachment.html>