From: Sam S. <sd...@gn...> - 2000-03-07 22:11:13
|
Bruno, why not make (sys::lib-directory) into a simple var sys::*lib-dir*? -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Lottery is a tax on statistics ignorants. MS is a tax on computer-idiots. |
From: Bruno H. <ha...@il...> - 2000-03-07 22:29:17
|
Sam writes: > why not make (sys::lib-directory) into a simple var sys::*lib-dir*? Why are (lisp-implementation-type) and (user-homedir-pathname) functions, not variables? Because sometimes they might do intelligent things behind the scenes, like looking up environment variables, trying various directories or things like that. In a distant future, you can even introduce optional arguments - which you can't do for a variable. In other words: Extensibility. Maintainability. Bruno |
From: Sam S. <sd...@gn...> - 2000-03-07 23:22:35
|
>>>> In message <200...@ob...> >>>> On the subject of "Re: sys::lib-directory" >>>> Sent on Tue Mar 07 17:29:47 EST 2000 >>>> Honorable Bruno Haible <ha...@il...> writes: >> Sam writes: >> >> > why not make (sys::lib-directory) into a simple var sys::*lib-dir*? >> >> Why are (lisp-implementation-type) and (user-homedir-pathname) >> functions, not variables? Because sometimes they might do >> intelligent things behind the scenes, like looking up environment >> variables, trying various directories or things like that. In a >> distant future, you can even introduce optional arguments - which >> you can't do for a variable. fine, can make it setf'able? is there a way to make ${lisplibdir} available in spvw.d? -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The only intuitive interface is the nipple. The rest has to be learned. |
From: Bruno H. <ha...@il...> - 2000-03-08 00:25:26
|
Sam writes: > fine, can make it setf'able? No, what should that be good for? When clisp is correctly installed, (sys::lib-directory) is correct. > is there a way to make ${lisplibdir} available in spvw.d? Yes, it is available as 'argv_lisplibdir' or 'funcall(L(lib_directory),0)'. Bruno |
From: Sam S. <sd...@gn...> - 2000-03-08 15:42:05
|
>>>> In message <200...@ob...> >>>> On the subject of "Re: sys::lib-directory" >>>> Sent on Tue Mar 07 20:48:23 EST 2000 >>>> Honorable Bruno Haible <ha...@il...> writes: >> >> > is there a way to make ${lisplibdir} available in spvw.d? >> >> Yes, it is available as 'argv_lisplibdir' or 'funcall(L(lib_directory),0)'. only when run with -B or through the driver, otherwise argv_lisplibdir is NULL and funcall(L(lib_directory),0) is an error. -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Those who can't write, write manuals. |
From: Bruno H. <ha...@il...> - 2000-03-08 18:18:06
|
Sam writes: > only when run with -B or through the driver, otherwise argv_lisplibdir > is NULL and funcall(L(lib_directory),0) is an error. Ah, now you tell the problem! You are not using the driver; you run ./lisp.run -M lispinit.mem by hand. The solution to the problem will be to compile _clisp.c locally with LOCALEDIR and LISPLIBDIR set appropriately. Bruno |
From: Sam S. <sd...@gn...> - 2000-03-08 19:58:46
|
>>>> In message <200...@ja...> >>>> On the subject of "Re: sys::lib-directory" >>>> Sent on Wed Mar 08 13:19:05 EST 2000 >>>> Honorable Bruno Haible <ha...@il...> writes: >> Sam writes: >> >> > only when run with -B or through the driver, otherwise argv_lisplibdir >> > is NULL and funcall(L(lib_directory),0) is an error. >> >> Ah, now you tell the problem! You are not using the driver; you run >> ../lisp.run -M lispinit.mem by hand. The solution to the problem >> will be to compile _clisp.c locally with LOCALEDIR and LISPLIBDIR >> set appropriately. this solves only a part of the problem. 1. I don't like the idea of a parameter which can be changed only at start time. users might have their own clhs.txt files, and as soon as we let them, they will want to switch between them at will. 2. as long as lisp.run can be started without the driver, some people will be doing that, and losing, and complaining. if you insist that this invocation method is inherrently deficient, it should be immpossible to start lisp.run interactively, i.e., unless started with the driver, repl should not be available. -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. MS Windows vs IBM OS/2: Why marketing matters more than technology... |
From: Bruno H. <ha...@il...> - 2000-03-08 21:39:56
|
Sam writes: > this solves only a part of the problem. > > 1. I don't like the idea of a parameter which can be changed only at > start time. users might have their own clhs.txt files, and as soon > as we let them, they will want to switch between them at will. Aha! Why didn't you say earlier that you are thinking about clhs.txt? If you want each user on a system to possibly have his own clhs.txt, while using the same clisp binary in /usr/local, the fix is obviously not to let the user override the entire lisplibdir; you add a function '*clhs-index-pathname*' so the user can override it in his .clisprc file. > 2. as long as lisp.run can be started without the driver, some people > will be doing that, and losing, and complaining. if you insist that > this invocation method is inherrently deficient, it should be > immpossible to start lisp.run interactively Making it impossible is too harsh; we need that possibility for debugging. I added a warning. > now you have /usr/local/lib/clisp/ *hardcoded* in lisp.run! You misunderstood the warning message. /usr/local is only an example; it's the default $(prefix). Please find and commit a better message. Bruno |
From: Sam S. <sd...@gn...> - 2000-03-08 22:20:49
|
>>>> In message <200...@ja...> >>>> On the subject of "Re: sys::lib-directory" >>>> Sent on Wed Mar 08 16:41:30 EST 2000 >>>> Honorable Bruno Haible <ha...@il...> writes: >> Sam writes: >> >> > this solves only a part of the problem. >> > >> > 1. I don't like the idea of a parameter which can be changed only at >> > start time. users might have their own clhs.txt files, and as soon >> > as we let them, they will want to switch between them at will. >> >> Aha! Why didn't you say earlier that you are thinking about >> clhs.txt? If you want each user on a system to possibly have his >> own clhs.txt, while using the same clisp binary in /usr/local, the >> fix is obviously not to let the user override the entire lisplibdir; >> you add a function '*clhs-index-pathname*' so the user can override >> it in his .clisprc file. what if we add something else there? it's easier to set one variable than 10. >> > now you have /usr/local/lib/clisp/ *hardcoded* in lisp.run! >> >> You misunderstood the warning message. /usr/local is only an example; >> it's the default $(prefix). Please find and commit a better message. I understand that. my point is that since you have something to offer as an example, why not go one step further and actually *try* this example before signalling an error? Again: why signal an error when it is so easy to do the right thing? -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. UNIX is a way of thinking. Windows is a way of not thinking. |
From: Bruno H. <ha...@il...> - 2000-03-08 22:55:04
|
Sam writes: > >> If you want each user on a system to possibly have his > >> own clhs.txt, while using the same clisp binary in /usr/local, the > >> fix is obviously not to let the user override the entire lisplibdir; > >> you add a function '*clhs-index-pathname*' so the user can override > >> it in his .clisprc file. > > what if we add something else there? > it's easier to set one variable than 10. The user may have a preference only for this one file and not the others; why should he need copy the other 9 into the same location? Also, the user might have some of the other 9 in different places. Symlinks are not the solution: not portable. > my point is that since you have something to offer as an example, why > not go one step further and actually *try* this example before > signalling an error? The clisp version installed in /usr/local might be a different, incompatible one. Unforeseeable errors could result. > why signal an error when it is so easy to do the right thing? Keep It Simple. If there is a way to do set the lib-directory in a 100% reliable way, moreover which doesn't need user intervention at all, you shouldn't invent a second one which is more complex and therefore only 90% reliable. Bruno |
From: Sam S. <sd...@gn...> - 2000-03-08 23:25:58
|
>> > what if we add something else there? >> > it's easier to set one variable than 10. >> >> The user may have a preference only for this one file and not the >> others; why should he need copy the other 9 into the same location? I meant that lib-dir should be setfable in addition to the setting all other individually. like lisp:*ansi* sets many variable which can be modified later individually. while I would still prefer to have lib-dir setfable, the benefits are not as obvious as I thought they were (as indicated by your staunch opposition), so I am hereby withdrawing my proposal. -- Sam Steingold (http://www.podval.org/~sds) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. If it has syntax, it isn't user friendly. |