The use of truenamize inside component-parent-pathname seems to work here. I was indeed concerned by the content of resolve-symlinks...
Thank you very much Faré. Faré wrote: > 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.beaud...@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@common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel >> _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
