From: Didier V. <di...@lr...> - 2010-09-30 07:37:48
|
Hi, it seems that when you use "sbcl --script" (or at least create an SBCL shell script with it), the file ~/.config/common-lisp/source-registry.conf is read by the script. In fact, I happen to like this behavior but I was surprised by it because it appears in contradiction with the semantics of --script, which is to *not* read any user init file. I'm not sure I have thought this through, so I'd like comment on this. Thanks. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Nikodemus S. <nik...@ra...> - 2010-09-30 09:06:48
|
On 30 September 2010 10:37, Didier Verna <di...@lr...> wrote: > it seems that when you use "sbcl --script" (or at least create an SBCL > shell script with it), the file > ~/.config/common-lisp/source-registry.conf is read by the script. > > In fact, I happen to like this behavior but I was surprised by it > because it appears in contradiction with the semantics of --script, > which is to *not* read any user init file. ASDF2 does the reading, so --script has no effect. The most SBCL can do is to provide a way to detect if it has been invoked with --script. Cheers, -- Nikodemus |
From: Robert G. <rpg...@si...> - 2010-09-30 15:19:52
|
On 9/30/10 Sep 30 -3:59 AM, Nikodemus Siivola wrote: > On 30 September 2010 10:37, Didier Verna <di...@lr...> wrote: > >> it seems that when you use "sbcl --script" (or at least create an SBCL >> shell script with it), the file >> ~/.config/common-lisp/source-registry.conf is read by the script. >> >> In fact, I happen to like this behavior but I was surprised by it >> because it appears in contradiction with the semantics of --script, >> which is to *not* read any user init file. > > ASDF2 does the reading, so --script has no effect. > > The most SBCL can do is to provide a way to detect if it has been > invoked with --script. Dumb question: "can do"? Does that mean "SBCL could be modified to provide a way to detect if it has been invoked with --script" or "SBCL now provides a way to detect if it has been invoked with --script"? thanks, r |
From: Didier V. <di...@lr...> - 2010-09-30 16:52:05
|
Nikodemus Siivola wrote: > ASDF2 does the reading, so --script has no effect. Yeah, I figured that much. But my concern was more along the lines of whether the current behavior is going to stay, or ... > The most SBCL can do is to provide a way to detect if it has been > invoked with --script. ... whether something like this will be used in future SBCL to prevent ASDF from reading the config file, which again would seem more coherent to me. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Faré <fa...@gm...> - 2010-09-30 17:02:15
|
On 30 September 2010 12:51, Didier Verna <di...@lr...> wrote: > Nikodemus Siivola wrote: > >> ASDF2 does the reading, so --script has no effect. > > Yeah, I figured that much. But my concern was more along the lines of > whether the current behavior is going to stay, or ... > >> The most SBCL can do is to provide a way to detect if it has been >> invoked with --script. > > ... whether something like this will be used in future SBCL to prevent > ASDF from reading the config file, which again would seem more coherent > to me. > You could open a bug for ASDF to change its behavior, but what exactly do you expect ASDF to do? Skip the user-configured systems but honor the system-configured systems? Honor or not honor the CL_SOURCE_REGISTRY environment variable? Start with builtin defaults only? Start with defaults somehow configured at the time that SBCL is compiled? Whichever way you put it, I don't see how you can justify any deviation from the normal behaviour based on the sole --script argument. How do you distinguish between scripts written by the user and scripts that come with the system? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "If men are good, you don't need government; if men are evil or ambivalent, you don't dare have one." — Robert LeFevre |
From: Robert G. <rpg...@si...> - 2010-09-30 17:09:26
|
On 9/30/10 Sep 30 -12:01 PM, Faré wrote: > On 30 September 2010 12:51, Didier Verna <di...@lr...> wrote: >> Nikodemus Siivola wrote: >> >>> ASDF2 does the reading, so --script has no effect. >> >> Yeah, I figured that much. But my concern was more along the lines of >> whether the current behavior is going to stay, or ... >> >>> The most SBCL can do is to provide a way to detect if it has been >>> invoked with --script. >> >> ... whether something like this will be used in future SBCL to prevent >> ASDF from reading the config file, which again would seem more coherent >> to me. >> > You could open a bug for ASDF to change its behavior, but what exactly > do you expect ASDF to do? Skip the user-configured systems but honor > the system-configured systems? Honor or not honor the > CL_SOURCE_REGISTRY environment variable? Start with builtin defaults > only? Start with defaults somehow configured at the time that SBCL is > compiled? Whichever way you put it, I don't see how you can justify > any deviation from the normal behaviour based on the sole --script > argument. How do you distinguish between scripts written by the user > and scripts that come with the system? This is a good point, but the --script argument is supposed to make behavior independent of user-specific configuration. It occurs to me that /all/ lisp implementations I know of are going to have some flavor of this problem (e.g., allegro has arguments for suppressing user- and site-specific configurations). This is probably a place where it would be useful to open a discussion with the implementers. I figure the best thing for ASDF to do is to expose an API that allows the implementations to disable user- and site- specific configuration at will. Probably we should move this to ASDF launchpad ticket, when we figure out what is The Right Thing. note that this is a complication that is unique to ASDF2. In ASDF1, all configuration is done in the user's normal lisp initialization, so user-configuration suppression will honor the implementations' configuration control API. Best, r |
From: Faré <fa...@gm...> - 2010-09-30 17:57:08
|
On 30 September 2010 13:09, Robert Goldman <rpg...@si...> wrote: > note that this is a complication that is unique to ASDF2. In ASDF1, all > configuration is done in the user's normal lisp initialization, so > user-configuration suppression will honor the implementations' > configuration control API. > Whatever the script is doing that was ensuring the systems will be found despite lack of configuration in ASDF1 will keep making things work in ASDF2; the user configuration file may be read, but whatever makes ASDF1 work will make those settings irrelevant. But yes, if there were a protocol to specify that we should skip user and/or system configuration, that would be nice. Problem being: if ASDF is to remain an optional component, then we'll need some non-portable thing that fetches this information differently from each and every of the supported implementations. Sigh. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The reason truth is stranger than fiction is that fiction has to make sense. |
From: Robert G. <rpg...@si...> - 2010-09-30 18:01:50
|
On 9/30/10 Sep 30 -12:56 PM, Faré wrote: > On 30 September 2010 13:09, Robert Goldman <rpg...@si...> wrote: >> note that this is a complication that is unique to ASDF2. In ASDF1, all >> configuration is done in the user's normal lisp initialization, so >> user-configuration suppression will honor the implementations' >> configuration control API. >> > Whatever the script is doing that was ensuring the systems will be > found despite lack of configuration in ASDF1 will keep making things > work in ASDF2; the user configuration file may be read, but whatever > makes ASDF1 work will make those settings irrelevant. > > But yes, if there were a protocol to specify that we should skip user > and/or system configuration, that would be nice. Problem being: if > ASDF is to remain an optional component, then we'll need some > non-portable thing that fetches this information differently from each > and every of the supported implementations. Sigh. Question: can't we simply support an api that toggles the two types of configuration on and off, and then leave it to the implementations to call this API when processing command-line arguments? I'm not sure about the internals of this configuration stuff, so I might be wrong. r |
From: Petter G. <sb...@gu...> - 2010-09-30 18:01:09
|
From: Robert Goldman <rpg...@si...> Subject: Re: [Sbcl-devel] --script and ASDF 2 Date: Thu, 30 Sep 2010 12:09:18 -0500 > This is probably a place where it would be useful to open a discussion > with the implementers. I figure the best thing for ASDF to do is to > expose an API that allows the implementations to disable user- and site- > specific configuration at will. You can do this to some extent by modifying asdf:*system-definition-search-functions* and calling asdf:initialize-source-registry I recently had some problems with ASDF loading old system wide libraries on my machine despite that I was running a local SBCL in my home directory with both the--no-userinit and --no-sysinit given on the command line. The solution was to call initialize-source-registry (thanks to Zach for pointing it out to me): (asdf:initialize-source-registry '(:source-registry :ignore-inherited-configuration)) Petter |
From: Didier V. <di...@lr...> - 2010-09-30 18:16:08
|
Robert Goldman <rpg...@si...> wrote: > This is probably a place where it would be useful to open a discussion > with the implementers. I figure the best thing for ASDF to do is to > expose an API that allows the implementations to disable user- and > site- specific configuration at will. Yup. > note that this is a complication that is unique to ASDF2. In ASDF1, > all configuration is done in the user's normal lisp initialization, so > user-configuration suppression will honor the implementations' > configuration control API. Exactly. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Didier V. <di...@lr...> - 2010-09-30 18:14:51
|
Faré <fa...@gm...> wrote: > On 30 September 2010 12:51, Didier Verna <di...@lr...> wrote: >> Nikodemus Siivola wrote: >> >>> ASDF2 does the reading, so --script has no effect. >> >> Yeah, I figured that much. But my concern was more along the lines of >> whether the current behavior is going to stay, or ... >> >>> The most SBCL can do is to provide a way to detect if it has been >>> invoked with --script. >> >> ... whether something like this will be used in future SBCL to prevent >> ASDF from reading the config file, which again would seem more coherent >> to me. >> > You could open a bug for ASDF to change its behavior, but what exactly > do you expect ASDF to do? I don't know, really :-) Like I said, I happen to like the current behavior, because it makes my life simpler, but there is something not totally coherent wrt the way SBCL used to behave with ASDF 1. Let me explain: - with SBCL / ASDF 1, the only way a user could configure the source registry was to set *central-registry* from a lisp file, typically .sbclrc. So when using scbl --script, that file is skipped, and so is the ASDF configuration. - now, the user would set the source registry in the config file, but then sbcl --script will still read it (because in fact, it is ASDF that reads it). So the consequence is that from one version of SBCL to another, there will be a change in behavior. I just thought the issue was important enough to be raised, eventhough I'm not totally clear on which behavior makes more sense. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Faré <fa...@gm...> - 2010-09-30 18:06:52
|
On 30 September 2010 14:01, Robert Goldman <rpg...@si...> wrote: > On 9/30/10 Sep 30 -12:56 PM, Faré wrote: >> But yes, if there were a protocol to specify that we should skip user >> and/or system configuration, that would be nice. Problem being: if >> ASDF is to remain an optional component, then we'll need some >> non-portable thing that fetches this information differently from each >> and every of the supported implementations. Sigh. > > Question: can't we simply support an api that toggles the two types of > configuration on and off, and then leave it to the implementations to > call this API when processing command-line arguments? > That only works if the implementation does the loading of ASDF. Should --script always require ASDF? Or something like --script --asdf or --asdf-script? Meh. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It’s amazing that the amount of news that happens in the world everyday always just exactly fits the newspaper. |
From: Robert G. <rpg...@si...> - 2010-09-30 18:43:19
|
On 9/30/10 Sep 30 -1:06 PM, Faré wrote: > On 30 September 2010 14:01, Robert Goldman <rpg...@si...> wrote: >> On 9/30/10 Sep 30 -12:56 PM, Faré wrote: >>> But yes, if there were a protocol to specify that we should skip user >>> and/or system configuration, that would be nice. Problem being: if >>> ASDF is to remain an optional component, then we'll need some >>> non-portable thing that fetches this information differently from each >>> and every of the supported implementations. Sigh. >> >> Question: can't we simply support an api that toggles the two types of >> configuration on and off, and then leave it to the implementations to >> call this API when processing command-line arguments? >> > That only works if the implementation does the loading of ASDF. Should > --script always require ASDF? Or something like --script --asdf or > --asdf-script? > Meh. Ugh. I don't think --asdf-script is going to be appropriate. Sigh. The only thing I can think of is to have some variable(s), in some known and pre-existing package, control this. This pre-configuration issue is one where I have always bonked my head on CL's package system. How do you permit the user to configure a system (in a package) that's not yet loaded? Emacs lisp doesn't have this issue, because it doesn't have packages, so simply using SETQ and DEFVAR correctly does The Right Thing. But I've never figured out anything better than either (1) crapping up CL-USER with variables for configuration or (2) crapping up the *FEATURES*. In this case, I think *FEATURES* is pretty inappropriate, so maybe we need to have CL-USER::*ASDF-LOAD-USER-CONFIG-P* and CL-USER::*ASDF-LOAD-SYSTEM-CONFIG-P* ick. r |
From: Didier V. <di...@lr...> - 2010-10-01 08:34:46
|
Robert Goldman <rpg...@si...> wrote: > This pre-configuration issue is one where I have always bonked my head > on CL's package system. How do you permit the user to configure a > system (in a package) that's not yet loaded? Emacs lisp doesn't have > this issue, because it doesn't have packages, so simply using SETQ and > DEFVAR correctly does The Right Thing. You delay the configuration until the package is loaded. I even have a very small library for doing that (cl-rcfiles). -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Nikodemus S. <nik...@ra...> - 2010-09-30 21:09:09
|
On 30 September 2010 21:01, Robert Goldman <rpg...@si...> wrote: > Question: can't we simply support an api that toggles the two types > of configuration on and off, and then leave it to the implementations > to call this API when processing command-line arguments? I don't know how: unless the implementation has ASDF already loaded, it isn't going to process any ASDF configs at startup. It seems to me that the issue here is really the configuration ASDF does when it is loaded -- by (REQUIRE :ASDF) or whatever. In SBCL, for example, --script implies both --no-userinit and --no-sysinit (among other things). The intention is to make things less dependent on user specific configurations. However, being able to find installed libraries is probably not such a configuration issue. Prior to ASDF2 for --script to have access to ASDF systems they pretty much had to be symlinked to ~/.sbcl/systems on /usr/local/lib/sbcl/systems. It is not obvious to me that seeing the source-registry is a downside. However, that said, I wonder how to make sure that ASDF configuration in general is consistent: consider for example a user who normally disables output-translations in initfiles. Since --script disables those initfiles, any ASDF systems used by them will use .cache -- presumably even if there were perfectly good fasl-files in the source directory already. Cheers, -- Nikodemus |
From: Robert G. <rpg...@si...> - 2010-09-30 21:20:53
|
On 9/30/10 Sep 30 -4:09 PM, Nikodemus Siivola wrote: > On 30 September 2010 21:01, Robert Goldman <rpg...@si...> wrote: > >> Question: can't we simply support an api that toggles the two types >> of configuration on and off, and then leave it to the implementations >> to call this API when processing command-line arguments? > > I don't know how: unless the implementation has ASDF already loaded, > it isn't going to process any ASDF configs at startup. I think that's why we have to use (yuck) a global variable in the CL-USER package as the "api." See earlier email. > > It seems to me that the issue here is really the configuration ASDF > does when it is loaded -- by (REQUIRE :ASDF) or whatever. > > In SBCL, for example, --script implies both --no-userinit and > --no-sysinit (among other things). The intention is to make things > less dependent on user specific configurations. > > However, being able to find installed libraries is probably not such a > configuration issue. I don't necessarily agree. It's easy for me to imagine a script that wants absolute control of what systems are going to be loaded. E.g., a script that's distributed with a fixed set of libraries. > > Prior to ASDF2 for --script to have access to ASDF systems they pretty > much had to be symlinked to ~/.sbcl/systems on > /usr/local/lib/sbcl/systems. > > It is not obvious to me that seeing the source-registry is a downside. > > However, that said, I wonder how to make sure that ASDF configuration > in general is consistent: consider for example a user who normally > disables output-translations in initfiles. Since --script disables > those initfiles, any ASDF systems used by them will use .cache -- > presumably even if there were perfectly good fasl-files in the source > directory already. Ouch. That suggests that what seemed like a sensible default case for interactive programmers might be really bad for use with --script. Unnecessary recompilation seems the least of our worries. Another possibility would be inappropriately crushing the user's existing fasls with fasls compiled under a different, --script-imposed configuration. best, r |
From: Daniel H. <dhe...@te...> - 2010-10-10 06:23:59
|
Sorry to join the party late. On Thu, 30 Sep 2010, Robert Goldman wrote: > On 9/30/10 Sep 30 -4:09 PM, Nikodemus Siivola wrote: >> In SBCL, for example, --script implies both --no-userinit and >> --no-sysinit (among other things). The intention is to make things >> less dependent on user specific configurations. >> >> However, being able to find installed libraries is probably not such a >> configuration issue. > > I don't necessarily agree. It's easy for me to imagine a script that > wants absolute control of what systems are going to be loaded. E.g., a > script that's distributed with a fixed set of libraries. And such a script should not rely on sbcl being invoked with --script in the first place. It should use a trick similar to Zach's as listed earlier. (asdf:initialize-source-registry '(:source-registry :ignore-inherited-configuration)) >> However, that said, I wonder how to make sure that ASDF configuration >> in general is consistent: consider for example a user who normally >> disables output-translations in initfiles. Since --script disables >> those initfiles, any ASDF systems used by them will use .cache -- >> presumably even if there were perfectly good fasl-files in the source >> directory already. > > Ouch. That suggests that what seemed like a sensible default case for > interactive programmers might be really bad for use with --script. > > Unnecessary recompilation seems the least of our worries. Another > possibility would be inappropriately crushing the user's existing fasls > with fasls compiled under a different, --script-imposed configuration. Yet another reason a build system should facilitate fasl-only (no sources present) loading. No chance of inappropriate recompilation. Though presumably a script using the above trick could also set all the other asdf parameters as appropriate. - Daniel |
From: Robert P. G. <rpg...@si...> - 2010-10-10 14:12:28
|
I take your points, Daniel, but mere technical ability to perform some task doesn't seem to me to entail a useful ability to do so. The expedients you propose seem to me likely to push script authoring into the realm of practical infeasibility. I wish I had a better answer. For reasons related to these I have, so far, decided (somewhat reluctantly) to stick to *central-registry*. R "Daniel Herring" <dhe...@te...> wrote: >Sorry to join the party late. > > >On Thu, 30 Sep 2010, Robert Goldman wrote: >> On 9/30/10 Sep 30 -4:09 PM, Nikodemus Siivola wrote: >>> In SBCL, for example, --script implies both --no-userinit and >>> --no-sysinit (among other things). The intention is to make things >>> less dependent on user specific configurations. >>> >>> However, being able to find installed libraries is probably not such a >>> configuration issue. >> >> I don't necessarily agree. It's easy for me to imagine a script that >> wants absolute control of what systems are going to be loaded. E.g., a >> script that's distributed with a fixed set of libraries. > >And such a script should not rely on sbcl being invoked with --script in >the first place. It should use a trick similar to Zach's as listed >earlier. > >(asdf:initialize-source-registry > '(:source-registry :ignore-inherited-configuration)) > > >>> However, that said, I wonder how to make sure that ASDF configuration >>> in general is consistent: consider for example a user who normally >>> disables output-translations in initfiles. Since --script disables >>> those initfiles, any ASDF systems used by them will use .cache -- >>> presumably even if there were perfectly good fasl-files in the source >>> directory already. >> >> Ouch. That suggests that what seemed like a sensible default case for >> interactive programmers might be really bad for use with --script. >> >> Unnecessary recompilation seems the least of our worries. Another >> possibility would be inappropriately crushing the user's existing fasls >> with fasls compiled under a different, --script-imposed configuration. > >Yet another reason a build system should facilitate fasl-only (no sources >present) loading. No chance of inappropriate recompilation. > >Though presumably a script using the above trick could also set all the >other asdf parameters as appropriate. > >- Daniel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
From: Nikodemus S. <nik...@ra...> - 2010-10-10 14:20:55
|
I think my stance on the environmental guarantees provided by --script is that: 1. SBCL initfiles are not processed. 2. SBCL contribs should be available. 3. If a script uses non-SBCL provided ASDF systems, then the onus to make them visible without initfiles is split between the user of the script and the writer. The only sensible alternative to this that I can see is to split SBCL initfiles into "interactive" and "non-interactive" initfiles, and make --script choose use the latter. Cheers, -- Nikodemus |
From: Robert G. <rpg...@si...> - 2010-10-10 17:13:58
|
On 10/10/10 Oct 10 -9:20 AM, Nikodemus Siivola wrote: > I think my stance on the environmental guarantees provided by --script is that: > > 1. SBCL initfiles are not processed. > > 2. SBCL contribs should be available. > > 3. If a script uses non-SBCL provided ASDF systems, > then the onus to make them visible without initfiles > is split between the user of the script and the writer. > > The only sensible alternative to this that I can see is to split SBCL > initfiles into "interactive" and "non-interactive" initfiles, and make > --script choose use the latter. > > Cheers, > > -- Nikodemus What about my proposal that the implementation be able to set two variables that would indicate to ASDF whether or not to read user and site initialization when output translations are initialized? The SBCL code that processes the --script arguments (or other command-line arguments) could handle these accordingly. best, r |
From: Attila L. <att...@gm...> - 2010-10-01 08:57:49
|
> This pre-configuration issue is one where I have always bonked my head > on CL's package system. How do you permit the user to configure a > system (in a package) that's not yet loaded? Emacs lisp doesn't have > this issue, because it doesn't have packages, so simply using SETQ and > DEFVAR correctly does The Right Thing. (eval-always (unless (find-package :foo) (make-package :foo))) (defparameter foo::*var* 42) (asdf:load-system :foo) and the :foo lib should use defvar's. the only issue can be that it may emit warnings. at least SBCL only warns if a defpackage form contains less stuff than the currently existing package. -- attila |
From: Robert G. <rpg...@si...> - 2010-10-01 12:55:13
|
On 10/1/10 Oct 1 -3:57 AM, Attila Lendvai wrote: >> This pre-configuration issue is one where I have always bonked my head >> on CL's package system. How do you permit the user to configure a >> system (in a package) that's not yet loaded? Emacs lisp doesn't have >> this issue, because it doesn't have packages, so simply using SETQ and >> DEFVAR correctly does The Right Thing. > > (eval-always > (unless (find-package :foo) > (make-package :foo))) > > (defparameter foo::*var* 42) > > (asdf:load-system :foo) > > and the :foo lib should use defvar's. > > the only issue can be that it may emit warnings. at least SBCL only > warns if a defpackage form contains less stuff than the currently > existing package. > Is this really safe? >From the CLHS definition of DEFPACKAGE: If defined-package-name already refers to an existing package, the name-to-package mapping for that name is not changed. If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition. So it looks like your snippet relies on undefined consequences. Best, r |
From: Robert G. <rpg...@si...> - 2010-10-10 17:23:39
|
On 10/10/10 Oct 10 -12:13 PM, Robert Goldman wrote: > On 10/10/10 Oct 10 -9:20 AM, Nikodemus Siivola wrote: >> I think my stance on the environmental guarantees provided by --script is that: >> >> 1. SBCL initfiles are not processed. >> >> 2. SBCL contribs should be available. >> >> 3. If a script uses non-SBCL provided ASDF systems, >> then the onus to make them visible without initfiles >> is split between the user of the script and the writer. >> >> The only sensible alternative to this that I can see is to split SBCL >> initfiles into "interactive" and "non-interactive" initfiles, and make >> --script choose use the latter. >> >> Cheers, >> >> -- Nikodemus > > What about my proposal that the implementation be able to set two > variables that would indicate to ASDF whether or not to read user and > site initialization when output translations are initialized? > > The SBCL code that processes the --script arguments (or other > command-line arguments) could handle these accordingly. The above really should have said INPUT LOCATIONS, not output... This does raise an issue, though --- even the venerable old asdf-binary-locations potentially could interact poorly with processing like --script, scattering binaries where they were not expected in normal processing.... cheers, r |
From: Faré <fa...@gm...> - 2010-10-10 20:37:54
|
Maybe it's time to standardize a common-lisp-configuration package that could eventually be provided by all implementations, with a few utility functions and variables, allowing to communicate with the environment. Candidate variables: *use-user-configuration* *use-system-configuration* Candidate functions: command-line-arguments () argv0 () getenv (name) ==> get the environment variable, or NIL setenv (name value) ==> set the environment variable, or unset (if value is NIL). callsym (package symbol &rest arguments) ==> call that function, or error getsym (package symbol &optional default) ==> value T NIL, or default NIL reason Maybe also some macros to enable or disable certain semantically significant "optimizations", like proper tail-calls or slot type-checking. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Demand Truly Free Health Care: where doctors need neither pay, food, sleep nor training, and hospitals grow on trees! |
From: Thomas de G. <bil...@gm...> - 2010-10-11 14:02:40
|
On 10/10/10 22:37, Faré wrote: > Maybe it's time to standardize a common-lisp-configuration package > that could eventually be provided by all implementations, with a few > utility functions and variables, allowing to communicate with the > environment. > > Candidate variables: > *use-user-configuration* > *use-system-configuration* > > Candidate functions: > command-line-arguments () > argv0 () > getenv (name) ==> get the environment variable, or NIL > setenv (name value) ==> set the environment variable, or unset (if > value is NIL). > callsym (package symbol&rest arguments) ==> call that function, or error > getsym (package symbol&optional default) ==> value T NIL, or default NIL reason > > Maybe also some macros to enable or disable certain semantically > significant "optimizations", like proper tail-calls or slot > type-checking. As a user, i see value in this. Could this solve the undefined-package-configuration problem too ? There must be something to generalize in a pragmatic way about configurations and their loading in various contexts. I'm not sure where to discuss this, maybe this is a broader subject than just sbcl-devel. -- Thomas de Grivel http://b.lowh.net/billitch |