This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
-----BEGIN PGP SIGNED MESSAGE----- I have uploaded a patch for load.c to ftp.red-bean.com://pub/guile/contrib/incoming/load-patch.tar.gz that implements my proposed modification to the load semantics--i.e. so that non-absolute filenames passed to load are always interpreted relative to the path of the file the load is in. My implementation correctly handles any number of recursive calls to load and both absolute and relative paths. Backwards compatibility is maintained. I only modified scm_primitive_load, but since all of the other load variants seem to eventually call this function, I think all combinations of loads do the right thing. It includes some test scripts that verify its correct operation. I have tested it under both Guile 1.2 and the 5/16 snapshot of Guile 1.3. Cordially, Steven G. Johnson PS. Since the load function maintains an internal state to keep track of the current path, this means it is not reentrant; problems will occur if multiple threads try to use loads with different relative paths simultaneously. I'm not sure if one should worry about this, however, since load doesn't seem to be strictly reentrant even without my patch--it accesses (and potentially writes) global state in the form of hook functions (not to mention the load-paths variants which use the global %load-paths variable). PPS. I rely on the assumption that "/" is the path delimeter. The rest of Guile seems to make this assumption as well, however. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0 for non-commercial use <http://www.pgp.com> Charset: noconv iQEVAwUBNV6fSu3fOMhN2WfhAQEDkQf/YNGJmOnZ1nobiYmysM5QYuaPRUsKJfAM KIH9pPrIRK+3nlBHebA6JtT/DlU5EYAmbWwoaFC+bm/TUxnQrw8lkby8w8Gkp03e Ze89FddhLi7+SzEDTjQoG42oVg3B5p+tebInbPkO5izT95n5AiKXdPovSj67A/h3 DfGYY7SiZ51RtLLzkk6W+NjcwIPare/lBRWy3A60ZH3Vrey1xceh/0wPCz81fj6n UIG9jNGdcyST04SU7xx35QmEdToAp1RLbpziD5PONHc3QSWY2lHv5xz+aDh8H+QA L9h2D4/awDrjGNwr74LYRI/mlDIxM4PEChH+Gk97+nUnfRCDI2PJ4w== =CWWN -----END PGP SIGNATURE-----