[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pre-computing paths [was: SRFI-59, SLIB, and SCHEME_LIBRARY_PATH]
| From: Derick Eddington <derick.eddington@xxxxxxxxx>
| Date: Tue, 13 Oct 2009 10:45:43 -0700
| On Sun, 2009-10-11 at 22:45 -0400, Aubrey Jaffer wrote:
| > | From: Derick Eddington <derick.eddington@xxxxxxxxx>
| > | Date: Wed, 07 Oct 2009 13:23:45 -0700
| > | ...
| > | Thanks for pointing-out these issues. The latency of always
| > | (i.e. for every program start-up) dynamically finding library
| > | files (which is what I think you're talking about) does sound
| > | like a serious concern for situations like you describe
| > | (i.e. unexpectedly long network file system latency).
| > | However, I think addressing this is beyond the purpose of this
| > | SRFI. This SRFI's purpose is to standardize what has (at this
| > | early stage) become the conventions for finding files of R6RS
| > | libraries. I think addressing the kind of issues you describe
| > | can be done with another SRFI which seamlessly fits on top of
| > | this SRFI (right?). I welcome more feedback about this.
| > If one tries to pre-compute paths when the only information is
| > the directory structure, then one must register all the files.
| > In order to not register unintended files, the directory
| > structure must be pristine, which is not always how humans work.
| > Looking at my development directories, I find experimental, test,
| > patched, and backup files nestled among the source-controlled
| > files.
| Okay, so pre-computing paths of library files should not be done
| from only the directory structure information. An SRFI layered on
| this SRFI should have some way of supplying the information of what
| paths to pre-compute.
Thinking about it, why is this problem any different when precomputing
paths than when dynamically computing them?