[asdf-devel] ASDF2: Please, no unwrapped calls to "truename".

[Faré]

Jean-Claude, I think you made a good point. I committed a fix -- is it
satisfactory to you?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Not only is there no contradiction between egoism and altruism, but no
altruism is possible without egoism - for what betterment to wish to an other
person devoid of selfish desire, to whom any change is indifferent?




On 5 April 2010 17:38, Jean-Claude Beaudoin
<jean.claude.beaudoin at gmail.com> wrote:
> Robert Goldman wrote:
>> On 4/5/10 Apr 5 -6:38 AM, Jean-Claude Beaudoin wrote:
>>> My very first attempt at using ASDF version 1.661 on my system
>>> ended-up in the debugger on a file-error signaled by
> ...
>>> I fixed the situation by modifying asdf::component-parent-pathname
>>> this way:
>>>
>>> (defun component-parent-pathname (component)
>>>    (aif (component-parent component)
>>>         (component-pathname it)
>>>         (or (ignore-errors (truename *default-pathname-defaults*))
>>>           *default-pathname-defaults*)))
>>
>> Can you explain why ignore-errors is correct here?  Seems like that OR
>> there is just hoping that something good will happen even if TRUENAME
>> raises an error.  Why is it better to quash an error and hope, instead
>> of bringing the error to the user's attention?
>
> Well, ignore-errors as used here is "correct" if one understands
> "correct" to mean "good enough" and not "the superior and exact solution".
> In that I merely followed the usage of all other calls to truename
> inside asdf.lisp. My thinking being that thus I was not introducing
> any new policy with respect to this element.  Also, the code here above
> is a return to the status quo ante, in old ASDF component-parent-pathname
> was happy to return *default-pathname-defaults* directly, without any
> processing through truename.  If it worked back in ASDF 1 it is probably
> not too bad a fallback plan in ASDF2.
>
> Some other form of wrapping, a handler-case of some kind, could also do.
> It is the unwrapped use of (truename *default-pathname-defaults*) that
> is problematic, ignore-errors is just one form of wrapping (the quick
> and easy one).
>
>>
>> I'm willing to believe that there IS a reason, but will you please
>> explain what it is?  For example, what was the case you encountered, and
>> why would it have been better to return *default-pathname-defaults*
>> instead of raising an error?  What were the *default-pathname-defaults*
>> in this case?
>
> There is no guarantee that the content of *default-pathname-defaults*
> is suitable for truename at all times. Being a global variable its value
> could be changed by any other thread unless pain is taken to rebind it
> locally to some value assured reasonable. One could simply do
> (setq *default-pathname-defaults* (make-pathname :type "fas")) and
> have every following evaluation of (truename *default-pathname-defaults*)
> signal a condition.
>
> No matter the precise value of *default-pathname-defaults*, any unwrapped
> (truename *default-pathname-defaults*) is pretty much the equivalent
> of a booby-trap waiting to explode.
>
> In my specific case *default-pathname-defaults* had value #P"" and on
> my system (truename #P"") is a sure way to get a condition signaled.
> Now you could argue that most current CL would evaluate (truename #P"")
> to the pathname of the current working directory. In my view that
> behavior of truename is a pretty liberal reading of the space between
> the lines of the ANSI CL standard. I may have to change that behavior
> to make it closer to what seems to have now achieved the status
> of more or less de facto tradition, but that is beyond the matter
> of my original post.
>
>>
>> My philosophy is more "signal errors strictly and as early as possible"
>> than "protect your users from errors in cases of bad data."
>>
>
> The net result I got when I tried (asdf:load-system :cffi) was
> an invocation of the debugger telling me that #P"" could not be found
> in the file system. If one wants to send casual users running for
> the door to never return one could hardly do better. Signaling
> an error to the user on this matter would require a lot more
> context information in order to make it in any way meaningful.
> And that could only be achieved by wrapping the offending call
> in some condition handler that would latter signal another
> augmented condition of its own. And thus I rest my case.
>
>>
>> Thank you,
>>
>> Robert
>
>
> _______________________________________________
> asdf-devel mailing list
> asdf-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>