I have some utility functions that I want to be defined
and accessible in every file/project/package that I work on.
Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
In article <········································@ziplip.com>,
·······@ziplip.com <·······@ziplip.com> wrote:
>I have some utility functions that I want to be defined
>and accessible in every file/project/package that I work on.
>
>Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
It depends on the Lisp implementation you're using, there is no standard
start-up file. So check the documentation.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
········@ziplip.com" <·······@ziplip.com> writes:
> I have some utility functions that I want to be defined
> and accessible in every file/project/package that I work on.
>
> Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
I have a package of miscellaneous code which i use with clisp, cmu and
sbcl. To make it accessible, I create a simple ASDF file and register
it with the common lisp controller (on Debian or Gentoo, maybe
others) like this: "clc-register myfoo.asd"
--
I like the way ONLY their mouths move.. They look like DYING OYSTERS
Matthew Kennedy <········@gentoo.com> writes:
> others) like this: "clc-register myfoo.asd"
That should have been "clc-register-user-package myfoo.asd"
--
..Everything is....FLIPPING AROUND!!
········@ziplip.com" <·······@ziplip.com> writes:
> I have some utility functions that I want to be defined
> and accessible in every file/project/package that I work on.
>
> Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
Personnaly, I have a file ~/.common.lisp containing all my Common-Lisp
initialization stuff, and I have my ~/.clisprc.lisp, ~/.sbclrc,
~/.cmucl-init.lisp, etc all load it with:
(LOAD (CONCATENATE 'STRING
(DIRECTORY-NAMESTRING *LOAD-PATHNAME*) ".common.lisp"))
before other implementation specific stuff.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon wrote:
> ········@ziplip.com" <·······@ziplip.com> writes:
>
>
>>I have some utility functions that I want to be defined
>>and accessible in every file/project/package that I work on.
>>
>>Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
>
>
> Personnaly, I have a file ~/.common.lisp containing all my Common-Lisp
> initialization stuff, and I have my ~/.clisprc.lisp, ~/.sbclrc,
> ~/.cmucl-init.lisp, etc all load it with:
>
> (LOAD (CONCATENATE 'STRING
> (DIRECTORY-NAMESTRING *LOAD-PATHNAME*) ".common.lisp"))
>
> before other implementation specific stuff.
The above is wrong. TRTTD is
(load (merge-pathnames (make-pathname :name ".common"
:type "lisp")
*load-pathname*)))
You may also want to throw in a :case :common in the MAKE-PATHNAME call.
I feel that whenever I see a pathname being cooked up by means of
CONCATENATE or FORMAT a big black abyss of unwanted consequences opens
under your feet :)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Pascal Bourguignon wrote:
>> ········@ziplip.com" <·······@ziplip.com> writes:
>>
>>>I have some utility functions that I want to be defined
>>>and accessible in every file/project/package that I work on.
>>>
>>>Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
>> Personnaly, I have a file ~/.common.lisp containing all my
>> Common-Lisp
>> initialization stuff, and I have my ~/.clisprc.lisp, ~/.sbclrc,
>> ~/.cmucl-init.lisp, etc all load it with:
>> (LOAD (CONCATENATE 'STRING
>> (DIRECTORY-NAMESTRING *LOAD-PATHNAME*) ".common.lisp"))
>> before other implementation specific stuff.
>
>
> The above is wrong. TRTTD is
>
> (load (merge-pathnames (make-pathname :name ".common"
> :type "lisp")
> *load-pathname*)))
>
> You may also want to throw in a :case :common in the MAKE-PATHNAME call.
>
> I feel that whenever I see a pathname being cooked up by means of
> CONCATENATE or FORMAT a big black abyss of unwanted consequences opens
> under your feet :)
Oh puh*leaze*. I don't believe that your form is any more the right
thing to do than Pascal's, and I challenge you to demonstrate why
yours is less likely to have unintended consequences.
(make-pathname :name "" :type "common.lisp")
(make-pathname :name ".common.lisp" :type "text/x-lisp-source")
Of course, Pascal's is about _as_ justified; at least one reasonable
interpretation of NAMESTRING and friends has every physical pathname
namestring starting with a colon. On the other hand, at least his
makes no pretence at portability, and it's not _aiming_ to; it's
aiming to load the ".common.lisp" file in the same directory as the
original file, on a Unix filesystem.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>········@ziplip.com" <·······@ziplip.com> writes:
>>>
>>>
>>>>I have some utility functions that I want to be defined
>>>>and accessible in every file/project/package that I work on.
>>>>
>>>>Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
>>>
>>>Personnaly, I have a file ~/.common.lisp containing all my
>>>Common-Lisp
>>>initialization stuff, and I have my ~/.clisprc.lisp, ~/.sbclrc,
>>>~/.cmucl-init.lisp, etc all load it with:
>>> (LOAD (CONCATENATE 'STRING
>>> (DIRECTORY-NAMESTRING *LOAD-PATHNAME*) ".common.lisp"))
>>>before other implementation specific stuff.
>>
>>
>>The above is wrong. TRTTD is
>>
>> (load (merge-pathnames (make-pathname :name ".common"
>> :type "lisp")
>> *load-pathname*)))
>>
>>You may also want to throw in a :case :common in the MAKE-PATHNAME call.
>>
>>I feel that whenever I see a pathname being cooked up by means of
>>CONCATENATE or FORMAT a big black abyss of unwanted consequences opens
>>under your feet :)
>
>
> Oh puh*leaze*. I don't believe that your form is any more the right
> thing to do than Pascal's, and I challenge you to demonstrate why
> yours is less likely to have unintended consequences.
>
> (make-pathname :name "" :type "common.lisp")
> (make-pathname :name ".common.lisp" :type "text/x-lisp-source")
My point is that there are *NO* unintended consequences in the above.
You get what you described.
Using CONCATENATE and, therefore, PARSE-NAMESTRING opens up the
"implementation dependent abyss" :) I was talking about.
I should have not used the "wrong" in my original post as it is
definitively too strong.
> Of course, Pascal's is about _as_ justified; at least one reasonable
> interpretation of NAMESTRING and friends has every physical pathname
> namestring starting with a colon. On the other hand, at least his
> makes no pretence at portability, and it's not _aiming_ to; it's
> aiming to load the ".common.lisp" file in the same directory as the
> original file, on a Unix filesystem.
Which, AFAIK, may give different results on different implementations on
a UNIX filesystem. Of course, maybe now all implementations agree about
how to PARSE-NAMESTRING on a Unix filesystem. I sincerely hope that
would be the case. I just have not tested it and I go for the "better
safe than sorry" approach.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Christophe Rhodes wrote:
>> Marco Antoniotti <·······@cs.nyu.edu> writes:
>>
>>>I feel that whenever I see a pathname being cooked up by means of
>>>CONCATENATE or FORMAT a big black abyss of unwanted consequences opens
>>>under your feet :)
>> Oh puh*leaze*. I don't believe that your form is any more the right
>> thing to do than Pascal's, and I challenge you to demonstrate why
>> yours is less likely to have unintended consequences.
>> (make-pathname :name "" :type "common.lisp")
>> (make-pathname :name ".common.lisp" :type "text/x-lisp-source")
>
> My point is that there are *NO* unintended consequences in the
> above. You get what you described.
>
> Using CONCATENATE and, therefore, PARSE-NAMESTRING opens up the
> "implementation dependent abyss" :) I was talking about.
>
> I should have not used the "wrong" in my original post as it is
> definitively too strong.
My point was that there is no particularly good reason for
(make-pathname :name ".common" :type "lisp")
to name a file with Unix name ".common.lisp". In fact, there's a very
good reason for it _not_ to: the type of a Unix file is very loosely
defined. What is the type of "readdir.2"? What is the type of
"clx_0.51.tar.gz"?
So there might well be a very good reason for an implementation on
Unix to treat its implementation-defined mapping (CLHS 19.1.2) from
pathnames to filenames as ignoring the type completely[*], or maybe
(as suggested in my second example) giving a hint to the system about
how it should be treated. But nothing, not even common sense, says
that /usr/man/readdir.2 should be named by a pathname with
:name "readdir" :type "2".
> Which, AFAIK, may give different results on different implementations
> on a UNIX filesystem. Of course, maybe now all implementations agree
> about how to PARSE-NAMESTRING on a Unix filesystem. I sincerely hope
> that would be the case. I just have not tested it and I go for the
> "better safe than sorry" approach.
Your version isn't safe. It is just as implementation-dependent as
going through PARSE-NAMESTRING, and (unlike on systems with a
well-defined concept of type in the filesystems) I don't think a
credible case can be made for saying that the only possible mapping
from CL pathnames to filesystem entries on Unix filesystems is the one
you happen to believe in.
Christophe
[*] Except see COMPILE-FILE-PATHNAME -- just slightly overspecified.
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Ok. Now I understand your point and I admit there is a flaw in my
reasoning.
The issue is that I was only considering the
PARSE-NAMESTRING <STRING> ==> <PATHNAME>
bit, while missing the
NAMESTRING <PATHNAME> ==> <STRING>
bit, most specifically under UNIX.
That does not mean that implementors could not agree on this issue.
Namely, the behavior of PARSE-NAMESTRING and NAMESTRING on UNIX filesystems.
Cheers
Marco
Christophe Rhodes wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Christophe Rhodes wrote:
>>
>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>
>>>
>>>>I feel that whenever I see a pathname being cooked up by means of
>>>>CONCATENATE or FORMAT a big black abyss of unwanted consequences opens
>>>>under your feet :)
>>>
>>>Oh puh*leaze*. I don't believe that your form is any more the right
>>>thing to do than Pascal's, and I challenge you to demonstrate why
>>>yours is less likely to have unintended consequences.
>>>(make-pathname :name "" :type "common.lisp")
>>>(make-pathname :name ".common.lisp" :type "text/x-lisp-source")
>>
>>My point is that there are *NO* unintended consequences in the
>>above. You get what you described.
>>
>>Using CONCATENATE and, therefore, PARSE-NAMESTRING opens up the
>>"implementation dependent abyss" :) I was talking about.
>>
>>I should have not used the "wrong" in my original post as it is
>>definitively too strong.
>
>
> My point was that there is no particularly good reason for
> (make-pathname :name ".common" :type "lisp")
> to name a file with Unix name ".common.lisp". In fact, there's a very
> good reason for it _not_ to: the type of a Unix file is very loosely
> defined. What is the type of "readdir.2"? What is the type of
> "clx_0.51.tar.gz"?
>
> So there might well be a very good reason for an implementation on
> Unix to treat its implementation-defined mapping (CLHS 19.1.2) from
> pathnames to filenames as ignoring the type completely[*], or maybe
> (as suggested in my second example) giving a hint to the system about
> how it should be treated. But nothing, not even common sense, says
> that /usr/man/readdir.2 should be named by a pathname with
> :name "readdir" :type "2".
>
>
>>Which, AFAIK, may give different results on different implementations
>>on a UNIX filesystem. Of course, maybe now all implementations agree
>>about how to PARSE-NAMESTRING on a Unix filesystem. I sincerely hope
>>that would be the case. I just have not tested it and I go for the
>>"better safe than sorry" approach.
>
>
> Your version isn't safe. It is just as implementation-dependent as
> going through PARSE-NAMESTRING, and (unlike on systems with a
> well-defined concept of type in the filesystems) I don't think a
> credible case can be made for saying that the only possible mapping
> from CL pathnames to filesystem entries on Unix filesystems is the one
> you happen to believe in.
>
> Christophe
>
> [*] Except see COMPILE-FILE-PATHNAME -- just slightly overspecified.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Christophe Rhodes wrote:
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> >>Pascal Bourguignon wrote:
> >>
> >>>········@ziplip.com" <·······@ziplip.com> writes:
> >>>
> >>>
> >>>>I have some utility functions that I want to be defined
> >>>>and accessible in every file/project/package that I work on.
> >>>>
> >>>>Where should I put the definitions? ~/.lisp ~/.cmucl ~/.clisp ?
> >>>
> >>>Personnaly, I have a file ~/.common.lisp containing all my
> >>>Common-Lisp
> >>>initialization stuff, and I have my ~/.clisprc.lisp, ~/.sbclrc,
> >>>~/.cmucl-init.lisp, etc all load it with:
> >>> (LOAD (CONCATENATE 'STRING
> >>> (DIRECTORY-NAMESTRING *LOAD-PATHNAME*) ".common.lisp"))
> >>>before other implementation specific stuff.
> >>
> >>
> >>The above is wrong. TRTTD is
> >>
> >> (load (merge-pathnames (make-pathname :name ".common"
> >> :type "lisp")
> >> *load-pathname*)))
> >>
> >>You may also want to throw in a :case :common in the MAKE-PATHNAME call.
> > Of course, Pascal's is about _as_ justified; at least one reasonable
> > interpretation of NAMESTRING and friends has every physical pathname
> > namestring starting with a colon. On the other hand, at least his
> > makes no pretence at portability, and it's not _aiming_ to; it's
> > aiming to load the ".common.lisp" file in the same directory as the
> > original file, on a Unix filesystem.
>
> Which, AFAIK, may give different results on different implementations
> on a UNIX filesystem. Of course, maybe now all implementations agree
> about how to PARSE-NAMESTRING on a Unix filesystem. I sincerely hope
> that would be the case. I just have not tested it and I go for the
> "better safe than sorry" approach.
Matter of fact, I just found one implementation where my way did not
work: ecl. Thank you for the correct statement.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Christophe Rhodes <·····@cam.ac.uk> writes:
> (make-pathname :name ".common.lisp" :type "text/x-lisp-source")
At first, I thought that was wrong; I had read somewhere that the
type of a source file should be "LISP". So I grepped the CLHS
and found the rule at 19.3.1.1.4 -- but it applies to logical
pathnames only.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> (make-pathname :name ".common.lisp" :type "text/x-lisp-source")
>
> At first, I thought that was wrong; I had read somewhere that the
> type of a source file should be "LISP". So I grepped the CLHS
> and found the rule at 19.3.1.1.4 -- but it applies to logical
> pathnames only.
... so that would be OK, then, if one as a Unix Lisp implementor
wanted to reflect the underlying filesystem semantics. However,
unfortunately, COMPILE-FILE-PATHNAME destroys such an implementation
technique: it is specified to return a pathname for which
The defaults for the output-file are taken from the pathname that
results from merging the input-file with the value of
*default-pathname-defaults*, except that the type component should
default to the appropriate implementation-defined default type for
compiled files.
In other words, to return
#.(make-pathname :name ".common.fasl" :type "application/x-sbcl-fasl"),
as I would like to, from
(compile-file-pathname (make-pathname :name ".common.lisp" :type "text/x-lisp-source"))
is non-conforming.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)