Re: Patch for finding the truename.

ok,
On Tuesday, Oct 28, 2003, at 16:47 Europe/Berlin, Gary King wrote:

> I agree with you completely and think that other Lisps should do 
> something similar so that interaction with the editor is facilitated. 
> Until this happens, then I think a work around (or set of work 
> arounds) like yours or like the load-truename function is useful.

let's think a bit more then about "portability workarounds". there are 
two approaches

1. ship application with a compatibility library which implements an 
"standard extensions". if they are not implemented / implementable for 
a given lisp version, the application won't run until they are. for 
things which have no counterpart in the standard this makes sense. 
parts of clocc are like this. with both positive and negative 
consequences.

2. ship applications with a patch library which makes the features of 
the standard behave in a standard way in situations which a given 
vendor has not considered or does not care to accommodate.

one needs to balance the two, but this instance appears to be a clear 
case where it is possible to follow path #2. one should make 
*load-pathname* "do the right" thing in all development environments 
rather than defining a parallel function which will require at least as 
much effort and, in the end, increases the complexity of the the 
development environment.

*load-pathname* is, in itself, a minor point, yet it points to the 
larger phenomena of downloading a portable application only to discover 
that there is a raft of "standard extensions", the intent of which one 
has to figure out, before one can even approach getting them to work.

...

>
>
> On Tuesday, October 28, 2003, at 10:36 AM, james anderson wrote:
>
>> my point was that digitool should be binding trash 
>> *loading-file-source-file* and bind *load-truename* instead.
>>
>> the equivalent of this.
>>
>> (advise ccl::selection-eval
>>         (let* ((*load-pathname* (ccl::stream-pathname (first 
>> arglist)))
>>                (*load-truename* (typecase *load-pathname*
>>                             (pathname (truename *load-pathname*))
>>                             (t nil))))
>>           (:do-it))
>>         :when :around
>>         :name :bind-load-pathname)
>>
>> hen you don't need to worry everywhere about the fred buffer special 
>> case.
>>
>> On Tuesday, Oct 28, 2003, at 15:23 Europe/Berlin, Gary King wrote:
>>
>>> On Monday, October 27, 2003, at 11:00 AM, james anderson wrote:
>>>
>>>>> (defun load-truename ()
>>>>>   "Returns a pathname that is useful for merging with filenames to 
>>>>> get a
>>>>> complete pathname for a file in the same directory as the one 
>>>>> currently being
>>>>> loaded.  This function is a more portable version of the Common 
>>>>> Lisp variable
>>>>> *load-pathname*, since not all vendors implemented that correctly."
>>>>
>>>> 1. why does one not want to just use *load-truename* for this?
>>>
>>> AFAIK, *load-truename* is only valid when a file is being loaded. 
>>> This function attempts to be accurate even in a buffer -- although 
>>> at this point that is only true for Digitool's MCL. To my mind, this 
>>> is very handy when defining systems interactively when the other 
>>> choice would be to continually save and load the system definition 
>>> file.
>>>
>>>> 2. wouldn't digitool be needed for this does open-mcl also define 
>>>> the ccl:*loading-file-source-file* symbol.
>>>
>>> I don't know about OpenMCL and ccl:*loading-file-source-file*.
>>>
>>>> i recall submitting a 5.0b bug about fred behaviour, as digitool 
>>>> should really be binding *load-truename* rather than in 
>>>> implementation specific variable with parallel semantics, since 
>>>> they do all of the other things - like warning about redefinition, 
>>>> as if they were loading from a file. my memory was they they agreed 
>>>> - in principle, but i've never checked whether it made it into the 
>>>> release. i'm still using a wrapped fred command which does just >>> 
>>>> that.
>>>
>>> Digitool does bind *load-truename* while loading. The 
>>> *loading-file-source-file* works in a buffer and while loading.
>>> -- 
>>> Gary Warren King, Lab Manager
>>> EKSL East, University of Massachusetts * 413 577 0176
>>>
>>> "no art, however minor, demands less than total dedication if you 
>>> want to excel in it."
>>>   -- Alberti
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: The SF.net Donation Program.
>>> Do you like what SourceForge.net is doing for the Open
>>> Source Community?  Make a contribution, and help us add new
>>> features and functionality. Click here: 
>>> http://sourceforge.net/donate/
>>> _______________________________________________
>>> cclan-list mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/cclan-list
>>>
>>
>>
> -- 
> Gary Warren King, Lab Manager
> EKSL East, University of Massachusetts * 413 577 0176
>
> Ye’ll tak the high road an’ I’ll tak yer wallet!
>   -- Terry Pratchett, the Wee Free Men
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> cclan-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cclan-list
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/