[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] [commit aafa6ac04] Initial draft of program to gr

From: Chris Hanson
Subject: Re: [MIT-Scheme-devel] [commit aafa6ac04] Initial draft of program to grovel over files looking for libraries.
Date: Sat, 24 Nov 2018 22:20:33 -0800

It sounds like we're talking about slightly different things.

The find-scheme-libraries! procedure is supposed to be called by an end user who has a bunch of libraries that they potentially want to import. It's not intended to be used during the import process, which works pretty much as you suggest, except that map from library name to pathname is created by a previous call to find-scheme-libraries!.

The loader's job _is_ simple -- when asked to import something, it looks up the required libraries and their dependencies in the in-memory database, then loads them in a dependency-mediated order. If one or more of the needed libraries aren't in the database, then an error is signaled and nothing else happens. The database itself is static at load time (modulo perhaps adding the content property that is deliberately not set for unloaded modules). I will probably add some additional checks such as making sure there have been no relevant changes since the pre-registrations were saved, but again that will simply cause the load to error out rather than try to repair.

It's the end user's responsibility to make sure that any libraries they want to import are pre-registered in the database. If changes are made to the library files are made, they need only re-run find-scheme-libraries!, which will update the database with the new information. The in-memory database isn't a cache -- it's the source of truth, as defined by the end user.

It's true that the deregistration of old versions of libraries aren't guaranteed to be correctly removed by the process, although it handles many cases now. That can be improved with more work; keeping track of registered pathnames better, etc. But ultimately we have to trust that the end user won't do anything that causes confusion, such as use symbolic/hard links. We can protect against that but not prevent it.

On Sat, Nov 24, 2018 at 9:32 PM Taylor R Campbell <address@hidden> wrote:
> Date: Sat, 24 Nov 2018 15:16:39 -0800
> From: Chris Hanson <address@hidden>
> I'm a little confused about what the problem is. Could you give specific
> examples?
> I'm also unsure about why having a file-system cache will help. Other than
> persistence, what advantage does having the cache in the file system
> provide? I can see an argument that the file system forces a particular
> organization to the cache, but the downside is that the implementation is
> more complex than one in memory.
> I've been assuming that it's OK to have more than one library in a single
> file. The file-system approach doesn't handle that naturally, though
> multiple links to a single file is reasonable.

What I'm asking for is that the loader's job be simple: to load an
installed library (foo bar baz), map it to a pathname, say
$libdir/mit-scheme-svm1/sld/foo/bar/baz.sld, and try to load that.  If
that means installing a set of libraries defined in a single file
requires making multiple symlinks to that file, that's fine.

Right now there's no cache, but if the process by which Scheme
discovers loadable libraries is to find everything named
*.scm/*.bin/*.com anywhere under $libdir/mit-scheme-svm1, it will be
tempting to make a cache since that's not going to be fast (and both
the on-disk cache and the in-memory cache that find-scheme-libraries!
currently creates will have to have some way to be invalidated).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]