From: Nikodemus S. <nik...@ra...> - 2005-12-07 08:00:42
|
(This is parallel to my earlier note about SB-EXT:*MODULE-PROVIDER-FUNCTIONS* traversal.) Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new locations pushed to the front take precendence and older ones serve as fallbacks. The behaviour undocumented. I believe that this is an unfortunate design as it means that a seemingly innocent PUSH can lead to totally different set of libraries being loaded as would be without. The system is unstable: a single idiomatic operation can have large and impossible to predict consequences. I would like to change ASDF to traverse it tail to head instead, so that (PUSH <DIR> *CENTRAL-REGISTRY*) can only make a previously failing (OOS 'LOAD-OP :FOO) succeed, but not alter the behaviour of a succeeding operation. This _would_ cause migration work for people whose setups deliberately operate on the head or tail already. However, I doubt this is much depended on outside personal initialization files since the current behaviour is not only undocumented but unstable. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Daniel B. <da...@te...> - 2005-12-07 11:32:55
|
On Wed, Dec 07, 2005 at 10:00:29AM +0200, Nikodemus Siivola wrote: > Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new locations > pushed to the front take precendence and older ones serve as fallbacks. > The behaviour undocumented. Though undocumented it was actually intentional: I was expecting that sites would have standard directories containing "release" code, and then individuals could push their personal directories - possibly containing development versions of systems with the same name - in front of that to override. I'm not sure if in the grand scheme of things this is a greater or lesser concern than the one you outline, but I use it a lot (when I use Lisp at all, anyway. Which is depressingly rarely) -dan |
From: Nikodemus S. <tsi...@cc...> - 2005-12-07 11:53:26
|
On Wed, 7 Dec 2005, Daniel Barlow wrote: > Though undocumented it was actually intentional: I was expecting that Ok. > I'm not sure if in the grand scheme of things this is a greater or > lesser concern than the one you outline, but I use it a lot (when I Can you estimate the effort changing this would entail for you? "Lots of fiddly bits all over my systems", "Something I do when hacking on stuff, but not as standard initfile feature." -- or something in between? ASDF is sufficiently widely deployed that I'm not going to change implicit things like this unless there is clear consensus. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Alexander K. <ale...@gm...> - 2005-12-07 12:37:08
|
On 12/7/05, Daniel Barlow <da...@te...> wrote: > On Wed, Dec 07, 2005 at 10:00:29AM +0200, Nikodemus Siivola wrote: > > Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new locations > > pushed to the front take precendence and older ones serve as fallbacks. > > The behaviour undocumented. > > Though undocumented it was actually intentional: I was expecting that > sites would have standard directories containing "release" code, and > then individuals could push their personal directories - possibly > containing development versions of systems with the same name - in > front of that to override. > This is also how environment variables like LD_LIBRARY_PATH, PATH etc work. To me it is the natural choice. astor |
From: Max-Gerd R. <m.r...@gm...> - 2005-12-07 12:46:36
|
Hello, On Wed, Dec 07, 2005 at 11:32:39AM +0000, Daniel Barlow wrote: > On Wed, Dec 07, 2005 at 10:00:29AM +0200, Nikodemus Siivola wrote: > > Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new locations= =20 > > pushed to the front take precendence and older ones serve as fallbacks.= =20 > > The behaviour undocumented. >=20 > Though undocumented it was actually intentional: I was expecting that > sites would have standard directories containing "release" code, and > then individuals could push their personal directories - possibly > containing development versions of systems with the same name - in > front of that to override. I'm kind of using ASDF in this way; excerp from my .sbclrc: .___ | (push #p"lispdir:systems;" asdf:*central-registry*) | (push #p"sbcldir:systems;" asdf:*central-registry*) | (push #p"coding:systems;" asdf:*central-registry*) "lispdir" is the most general directory, then there is a site-directory for sbcl (containing e.g. a special CLX). On my former notebook there was another special site-directory for OpenMCL, and now there is one for cmucl. The third level is my current hacking directory ("coding"), with asdf-files for my own programmes, or modified parts/sytems that might also be included in projects on the first level (e.g. McCLIM). This is just the way I'm using it for now. Bye, Max --=20 Max-Gerd Retzlaff <m.r...@gm...> For your amusement: If you're careful enough, nothing bad or good will ever happen to you. |
From: Nikodemus S. <nik...@ra...> - 2005-12-07 13:22:25
|
On Wed, 7 Dec 2005, Max-Gerd Retzlaff wrote: > | (push #p"lispdir:systems;" asdf:*central-registry*) > | (push #p"sbcldir:systems;" asdf:*central-registry*) > | (push #p"coding:systems;" asdf:*central-registry*) Are you intentionally overriding the SBCL-provided directories in *central-registry*? In any case it seems to me that changing the way *central-registry* works is a bad idea and a good way to increase the amount of pain in the world. So, I revise my position completely (always good for a laugh): 1) Keep *central-registry* and *module-provider-functions* traversal as is. 2) Make ASDF add its provider function the _end_ of *m-p-f*, so that ASDF modules will not accidentally override contribs. (Not all contribs have .asd files.) 3) Add sysdef-contrib-search-function to the head of *system-definition-search-functions* that looks in (MERGE-PATHNAMES "systems/" (TRUENAME (POSIX-GETENV "SBCL_HOME"))) -- and remove the corresponding entry from *central-registry*. This is also needed with 2) for consistency between (OOS 'LOAD-OP X) and (REQUIRE X). 4) Document all of this properly. End result: current overriding behaviour for user-space components, but overriding a contrib takes extra work: you need to add new functions to *m-p-f* and *s-d-s-f* to do that, instead of just pushing on *central-registry*. How does that sound? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Rudi S. <ru...@co...> - 2005-12-07 13:49:46
Attachments:
PGP.sig
|
On 7. Dez 2005, at 14:22, Nikodemus Siivola wrote: > End result: current overriding behaviour for user-space components, > but overriding a contrib takes extra work: you need to add new > functions to *m-p-f* and *s-d-s-f* to do that, instead of just > pushing on *central-registry*. > > How does that sound? Sounds good to me - IIUC, this passes the asdf-install test (can the user inadvertently break asdf-install on sbcl?) while still making it easy for developers to override stuff they're working on. Rudi |
From: Max-Gerd R. <m.r...@gm...> - 2005-12-07 14:05:43
|
On Wed, Dec 07, 2005 at 03:22:13PM +0200, Nikodemus Siivola wrote: > On Wed, 7 Dec 2005, Max-Gerd Retzlaff wrote: >=20 > > | (push #p"lispdir:systems;" asdf:*central-registry*) > > | (push #p"sbcldir:systems;" asdf:*central-registry*) > > | (push #p"coding:systems;" asdf:*central-registry*) >=20 > Are you intentionally overriding the SBCL-provided directories > in *central-registry*? I'm just pushing on it! :) My complete asdf::*central-registry* in SBCL looks like this: (#P"CODING:SYSTEMS;" #P"SBCLDIR:SYSTEMS;" #P"LISPDIR:SYSTEMS;" (MERGE-PATHNAMES ".sbcl/systems/" (USER-HOMEDIR-PATHNAME)) (MERGE-PATHNAMES "site-systems/" (TRUENAME (POSIX-GETENV "SBCL_HOME"))) (MERGE-PATHNAMES "systems/" (TRUENAME (POSIX-GETENV "SBCL_HOME"))) *DEFAULT-PATHNAME-DEFAULTS*) ~/.sbcl/systems is empty, and so is SBCL_HOME/site-systems. SBCL_HOME/system contains the normal sb-*.asd files as well as asdf-install.ads. > 2) Make ASDF add its provider function the _end_ of *m-p-f*, so that ASDF > modules will not accidentally override contribs. (Not all contribs > have .asd files.) Don't you think it might be confusing that the last system directory that the user has added will not get the highest priority? > 3) Add sysdef-contrib-search-function to the head of > *system-definition-search-functions* that looks in > (MERGE-PATHNAMES "systems/" (TRUENAME (POSIX-GETENV "SBCL_HOME"))) > -- and remove the corresponding entry from *central-registry*. > This is also needed with 2) for consistency between (OOS 'LOAD-OP X) > and (REQUIRE X). Huh, and what about people who have copies of these systems and hack on them? That might be highly inconvenient. If I have specified that my copy should have a higher priority (=3D is in a system directory more to the top of asdf:*central-registry*) then I want it to be selected. Why should a user have a copy of a system in one of the other directories if he or she doesn't want it? If he has then he might know what he does. And a beginner will probably have only one systems directory of his own at all, I guess. > End result: current overriding behaviour for user-space components, but > overriding a contrib takes extra work: you need to add new functions to > *m-p-f* and *s-d-s-f* to do that, instead of just pushing on > *central-registry*. Ah, okay, this way.. But I think the simpler solution is better, that is only one way to add new system directories. Even demanding to add new functions is not the most convenient solution. Bye, Max --=20 Max-Gerd Retzlaff <m.r...@gm...> For your amusement: If you're careful enough, nothing bad or good will ever happen to you. |
From: Rudi S. <ru...@co...> - 2005-12-07 14:18:28
Attachments:
PGP.sig
|
On 7. Dez 2005, at 14:57, Max-Gerd Retzlaff wrote: > Ah, okay, this way.. But I think the simpler solution is better, that > is only one way to add new system directories. Even demanding to add > new functions is not the most convenient solution. There's a steady trickle of bug reports of users who end up with non- working asdf-install on sbcl because they installed the portable asdf- install and have a common common lisp init file. Nikodemus's proposal, if I understood it correctly, would fix this. Rudi |
From: GP l. <fp...@cl...> - 2005-12-07 22:43:16
|
From: Daniel Barlow <da...@te...> Date: Wed, 7 Dec 2005 11:32:39 +0000 On Wed, Dec 07, 2005 at 10:00:29AM +0200, Nikodemus Siivola wrote: > Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new locations > pushed to the front take precendence and older ones serve as fallbacks. > The behaviour undocumented. Though undocumented it was actually intentional: I was expecting that sites would have standard directories containing "release" code, and then individuals could push their personal directories - possibly containing development versions of systems with the same name - in front of that to override. In fact I do exactly that. I use different usernames for different projects, it is unix after all. So there is a global ASDF setup, followed by a specialization setup. Ordering would be strange with this suggested change. r |
From: Nikodemus S. <tsi...@cc...> - 2005-12-07 16:06:11
|
On Wed, 7 Dec 2005, David Lichteblau wrote: > If that advice isn't valid anymore, just make sure that we all know what > the new advice is! The new advice would eg. be (untested): (defpackage :asdf-user (:use :cl :asdf :sb-ext) (:import-from :asdf "SYSDEF-CENTRAL-REGISTRY-SEARCH" "MODULE-PROVIDE-ASDF")) (in-package :asdf-user) ;;; Systems linked here will take precedence over anything else (defvar *override-registry* '("/home/david/hacking/systems/")) ;;; Take care of ASD:OOS by adding a search function that ;;; overrides *central-registry*. Being lazy we leave the ;;; actual implementation intact. Ain't dynamic variables nice? (push (defun sysdef-override-search (name) (let ((*central-registry* *override-registry*)) (sysdef-central-registry-search name))) *system-definition-search-functions*) ;;; Take care of REQUIRE by adding a provider function that ;;; overrides the contrib provider. Do the same *central-registry* ;;; rebinding trick here so that _regular_ systems in the normal ;;; central-registry don't accidentally trump contribs. (push (defun provide-override-module (name) (let ((*central-registry* *override-registry*)) (module-provide-asdf name))) *module-provider-functions*) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Gary K. <gw...@me...> - 2005-12-08 21:36:38
Attachments:
smime.p7s
|
I think that whether or not this is done there should be some standardized interface to the *central-registry* and to the whole system lookup process. Part of this would be something like: add-path-to-registry <path> &optional (precedence :higher) remove-path <path> map-paths <fn> There could also be a mechanism that would realize that a system can be found in multiple places and provides a call back to break ties (perhaps defaulting to the most recent / highest version). Either of these proposals is likely to get overly complex fast (which perhaps means that they aren't a good idea! <sad face>) but I think that exposing the *central-registry* variable is a bad idea... On Dec 7, 2005, at 3:00 AM, Nikodemus Siivola wrote: > (This is parallel to my earlier note about SB-EXT:*MODULE-PROVIDER- > FUNCTIONS* traversal.) > > Currently ASDF traverses *CENTRAL-REGISTRY* head-to-tail: new > locations pushed to the front take precendence and older ones serve > as fallbacks. The behaviour undocumented. > > I believe that this is an unfortunate design as it means that a > seemingly > innocent PUSH can lead to totally different set of libraries being > loaded > as would be without. The system is unstable: a single idiomatic > operation > can have large and impossible to predict consequences. > > I would like to change ASDF to traverse it tail to head instead, so > that (PUSH <DIR> *CENTRAL-REGISTRY*) can only make a previously > failing (OOS 'LOAD-OP :FOO) succeed, but not alter the behaviour of > a succeeding operation. > > This _would_ cause migration work for people whose setups > deliberately operate on the head or tail already. However, I doubt > this is much depended on outside personal initialization files > since the current behaviour is not only undocumented but unstable. > > Cheers, > > -- Nikodemus Schemer: "Buddha is small, clean, and > serious." > Lispnik: "Buddha is big, has hairy armpits, and > laughs." > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > cclan-list mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclan-list -- Gary Warren King metabang.com http://www.metabang.com/ |