This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
| 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?