[armedbear-devel] translate-logical-pathname and :wild-inferiors regression
A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more. e.g. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") Used to work, but now fails. Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. -Alan
On 1/17/10 11:09 PM, Alan Ruttenberg wrote:
A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more.
e.g.
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Used to work, but now fails.
Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS.
In both the released abcl-0.18.0 and trunk (as of r12383), I don't see this bug. getting CL-USER> (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/IDO:IMMUNOLOGY;" Could you please provide more information about which version of ABCL has this problem? Note to developers: the task of determining which version of ABCL people report problems to us would be simplified if we included better versioning wrt. SVN. There is a "version.src" Ant property that is stored in the abcl.jar file to keep track of versions, but when I last looked into it I never found a reasonable way to set it from Ant, as there is no built-in support in Ant for Subversion. If we could depend on the existence of a 'svn' client binary in the PATH, we could parse its output, but this seems like a bad bet under Windows as a sizable number of people presumably use Explorer Shell extensions like TortoiseSVN. It looks like a possible route would be to parse the contents of '.svn/entries' if it exists to take a stab at reporting which SVN version abcl.jar was built from. Without access to an SVN client we couldn't tell reliably if the source has been modified from that SVN version, but it would give us a decent place to start. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
In 12389 just checked out and compiled just now. CL-USER(4): (setf (logical-pathname-translations "ido") '((#P"IDO:IDO-CORE;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/ido-core/**/*.*") (#P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*") (#P"IDO:TOOLS;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/tools/**/*.*") (#P"IDO:LIB;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/lib/**/*.*"))) CL-USER(5): (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") Debugger invoked on condition of type SIMPLE-ERROR: Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. Restarts: 0: TOP-LEVEL Return to top level. I patched it with the following, but don't know if it's the right thing (defun translate-directory-components-aux (src from to case) (cond ((and (null src) (null from) (null to)) NIL) ((and to (not (member (car to) '(:wild :wild-inferiors)))) (cons (casify (car to) case) (translate-directory-components-aux src from (cdr to) case))) --> ((and (not src) (eq (car from) :wild-inferiors) (eq (car to) :wild-inferiors)) (translate-directory-components-aux src (cdr from) (cdr to) case)) --> ((not (and src from)) ;; both are NIL --> TO is a wildcard which can't be matched ;; either is NIL --> SRC can't be fully matched against FROM, vice versa (throw 'failed-match)) ... I concur btw that having a function that generates a report to include for the developers would be a good thing. Svn version, possibly the svn diff wrt to that, java version, etc. -Alan On Mon, Jan 18, 2010 at 5:12 AM, Mark Evenson <evenson@panix.com> wrote:
On 1/17/10 11:09 PM, Alan Ruttenberg wrote:
A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more.
e.g.
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Used to work, but now fails.
Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS.
In both the released abcl-0.18.0 and trunk (as of r12383), I don't see this bug. getting
CL-USER> (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/IDO:IMMUNOLOGY;"
Could you please provide more information about which version of ABCL has this problem?
Note to developers: the task of determining which version of ABCL people report problems to us would be simplified if we included better versioning wrt. SVN. There is a "version.src" Ant property that is stored in the abcl.jar file to keep track of versions, but when I last looked into it I never found a reasonable way to set it from Ant, as there is no built-in support in Ant for Subversion. If we could depend on the existence of a 'svn' client binary in the PATH, we could parse its output, but this seems like a bad bet under Windows as a sizable number of people presumably use Explorer Shell extensions like TortoiseSVN. It looks like a possible route would be to parse the contents of '.svn/entries' if it exists to take a stab at reporting which SVN version abcl.jar was built from. Without access to an SVN client we couldn't tell reliably if the source has been modified from that SVN version, but it would give us a decent place to start.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Acknowledge and logged as [ticket 82][1]. Since I am nearing the end of overhauling the PATHNAME internals, I will make sure this is fixed in those changes which should hit the trunk in the next week at my current pace. Its a bit of a mystery how this broke, but I have added a test to the ABCL unit tests to ensure that this will stay fixed. I must confess to never having really understood logical pathnames before, so this is a bit of (welcome?) education here, as I was firmly in [camp #3][2]. [1]: http://trac.common-lisp.net/armedbear/ticket/82 [2]: http://xach.livejournal.com/242280.html -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Fri, Jan 29, 2010 at 4:03 AM, Mark Evenson <evenson@panix.com> wrote:
On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Acknowledge and logged as [ticket 82][1].
Since I am nearing the end of overhauling the PATHNAME internals, I will make sure this is fixed in those changes which should hit the trunk in the next week at my current pace. Its a bit of a mystery how this broke, but I have added a test to the ABCL unit tests to ensure that this will stay fixed.
Thanks :)
I must confess to never having really understood logical pathnames before, so this is a bit of (welcome?) education here, as I was firmly in [camp #3][2].
Yah. The reason I have them is because I work with others from svn and need to refer in my programs to elements from wherever those files happen to land. -Alan
[1]: http://trac.common-lisp.net/armedbear/ticket/82 [2]: http://xach.livejournal.com/242280.html
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 1/29/10 4:12 PM, Alan Ruttenberg wrote:
On Fri, Jan 29, 2010 at 4:03 AM, Mark Evenson<evenson@panix.com> wrote:
On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Acknowledge and logged as [ticket 82][1]. […]
Somehow, the more I learn about Pathnames, the less I understand. First off, I think that the SETF on LOGICAL-PATHNAME-TRANSLATION should never use the #P for its arguments as you had in your example: (setf (logical-pathname-translations "ido") '((#P"IDO:IDO-CORE;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/ido-core/**/*.*"))) […] because it doesn't do what you might expect, namely the #p"IDO:IDO-CORE;**;*.*" is not interpreted as a logical pathname when read by the SHARP_P reader. You end up with an Pathname whose NAME is "IDO:IDO-CORE;**;*.*" and other components are nil. That this ever worked in ABCL is mysterious. Based on a canvas of open source Lisps available to me, SBCL, ECL, and CCL all signal errors on being input this form, for a variety of differing reasons. clisp accepts the form, but fails to record it as a logical pathname. Second, refactoring your test case away from logical pathnames down to the use to TRANSLATE-PATHNAME, I derive the following use of TRANSLATE-PATHNAME to be equivalent to the behavior you want: (translate-pathname "/immunology/" "/immunology/**/" "/usr/home/**") which you want to output #p"/usr/home/immunology/" but none of the other Lisps I checked (SBCL, ECL, CCL, and clisp) work this way, they all return #p"/usr/home/" I think they do this to avoid the case for which Thomas Russ reported a bug where (translate-pathname "/immunology/" "/immunology/**/" "/usr/home/immunology/**") should return #p"/usr/home/immunology/" not #p"/usr/home/immunology/immunology/" as was the pre-r12283 ABCL behavior. So, I am a bit confused on how to proceed. The behavior of TRANSLATE-PATHNAME is implementation specific. From fuddling around with the old implementation and the new one, I seem to be able to get either behavior but not both and they seem logically incompatible but I haven't proved that definitely to myself. Since the other CL implementations exhibit the same behavior as current ABCL I need either a) evidence that another Lisp works the way that Alan expects (and does it then exhibit the same behavior that is a bug to Thomas Russ?) or b) a clear semantics that I can implement that satisfy both uses. Input kindly solicited from one and all. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Wed, Feb 3, 2010 at 8:51 AM, Mark Evenson <evenson@panix.com> wrote:
On 1/29/10 4:12 PM, Alan Ruttenberg wrote:
On Fri, Jan 29, 2010 at 4:03 AM, Mark Evenson<evenson@panix.com> wrote:
On 1/18/10 4:51 PM, Alan Ruttenberg wrote:
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Acknowledge and logged as [ticket 82][1].
[…]
Somehow, the more I learn about Pathnames, the less I understand.
First off, I think that the SETF on LOGICAL-PATHNAME-TRANSLATION should never use the #P for its arguments as you had in your example:
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
(setf (logical-pathname-translations "ido") '((#P"IDO:IDO-CORE;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/ido-core/**/*.*")))
[…]
because it doesn't do what you might expect, namely the #p"IDO:IDO-CORE;**;*.*" is not interpreted as a logical pathname when read by the SHARP_P reader. You end up with an Pathname whose NAME is "IDO:IDO-CORE;**;*.*" and other components are nil. That this ever worked in ABCL is mysterious. Based on a canvas of open source Lisps available to me, SBCL, ECL, and CCL all signal errors on being input this form, for a variety of differing reasons. clisp accepts the form, but fails to record it as a logical pathname.
Second, refactoring your test case away from logical pathnames down to the use to TRANSLATE-PATHNAME, I derive the following use of TRANSLATE-PATHNAME to be equivalent to the behavior you want:
(translate-pathname "/immunology/" "/immunology/**/" "/usr/home/**")
which you want to output
#p"/usr/home/immunology/"
but none of the other Lisps I checked (SBCL, ECL, CCL, and clisp) work this way, they all return
#p"/usr/home/"
I think they do this to avoid the case for which Thomas Russ reported a bug where
(translate-pathname "/immunology/" "/immunology/**/" "/usr/home/immunology/**")
should return
#p"/usr/home/immunology/"
not
#p"/usr/home/immunology/immunology/"
as was the pre-r12283 ABCL behavior.
So there's some wierdness in sbcl: * (translate-pathname "/immunology/foo/" "/immunology/**/" "/usr/home/bar/**") #P"/usr/home/bar/" * (translate-pathname "/immunology/foo/" "/immunology/**/" "/usr/home/bar/**/") #P"/usr/home/bar/foo/" (translate-pathname "/immunology/foo/" "/immunology/**" "/usr/home/bar/**") debugger invoked on a SIMPLE-ERROR: Pathname components from SOURCE and FROM args to TRANSLATE-PATHNAME did not match: ("immunology" "foo") ("immunology") I agree this is confusing. But my case was a simple regression and that's my immediate concern. -Alan
So, I am a bit confused on how to proceed. The behavior of TRANSLATE-PATHNAME is implementation specific. From fuddling around with the old implementation and the new one, I seem to be able to get either behavior but not both and they seem logically incompatible but I haven't proved that definitely to myself. Since the other CL implementations exhibit the same behavior as current ABCL I need either a) evidence that another Lisp works the way that Alan expects (and does it then exhibit the same behavior that is a bug to Thomas Russ?) or b) a clear semantics that I can implement that satisfy both uses.
Input kindly solicited from one and all.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 2/3/10 6:38 PM, Alan Ruttenberg wrote: […]
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
I don't get that, I see the following: dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (setf (logical-pathname-translations "ido") '(("IDO:IMMUNOLOGY;**;*.*" "/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*"))) (("IDO:IMMUNOLOGY;**;*.*" "/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*")) * (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/" Which is missing the trailing "/immunology/". Which SBCL are you using? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2010/2/3 Mark Evenson <evenson@panix.com>:
On 2/3/10 6:38 PM, Alan Ruttenberg wrote: […]
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
I don't get that, I see the following:
dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (setf (logical-pathname-translations "ido") '(("IDO:IMMUNOLOGY;**;*.*" "/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*")))
This part is unnecessary. The call to translate-pathname below doesn't use it.
(("IDO:IMMUNOLOGY;**;*.*"
"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*")) * (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/"
Which is missing the trailing "/immunology/". Which SBCL are you using?
Same answer I get. There shouldn't be a trailing "/immunology/" in the above example. In my environment, after loading the *load-truename* relative form I gave in my previous email, from the file (load "/Users/alanr/repos/infectious-disease-ontology/trunk/src/tools/ido.asd") Then: (truename "ido:immunology;ido-s4lps-tlr.xlsx") Calling (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;IDO-S4LPS-TLR.XLSX" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*") TRANSLATE-PATHNAME returned #P"/users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/ido-s4lps-tlr.xlsx" in sbcl * (truename "ido:immunology;ido-s4lps-tlr.xlsx") 0: (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;IDO-S4LPS-TLR.XLSX.NEWEST" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*") 0: TRANSLATE-PATHNAME returned #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/ido-s4lps-tlr.xlsx" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/ido-s4lps-tlr.xlsx" * This is SBCL 1.0.29. -Alan
On 2/3/10 7:32 PM, Alan Ruttenberg wrote:
2010/2/3 Mark Evenson<evenson@panix.com>:
On 2/3/10 6:38 PM, Alan Ruttenberg wrote: […]
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
I don't get that, I see the following:
dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at<http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (setf (logical-pathname-translations "ido") '(("IDO:IMMUNOLOGY;**;*.*" "/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*")))
This part is unnecessary. The call to translate-pathname below doesn't use it.
Now I'm real confused, because without telling the Lisp that "IDO:" is a logical hostname prefix I get: dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/IDO:IMMUNOLOGY;" Which is definitely not what you want, right? Or do you have this translations defined in initialization files (i.e. "~/.sbclrc")? With the IDO logical pathname host defined with the SETF on LOGICAL-PATHNAME-TRANSLATIONS, I thought you wanted this behavior: (translate-pathname #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/" which is what I observe pre-r12283 ABCL doing. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Wed, Feb 3, 2010 at 2:03 PM, Mark Evenson <evenson@panix.com> wrote:
On 2/3/10 7:32 PM, Alan Ruttenberg wrote:
2010/2/3 Mark Evenson<evenson@panix.com>:
On 2/3/10 6:38 PM, Alan Ruttenberg wrote: […]
First off, is the example I gave in this thread. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
This succeeds in SBCL and throws an error (regressing) in ABCL. So that part is an issue no matter what.
I don't get that, I see the following:
dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at<http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (setf (logical-pathname-translations "ido") '(("IDO:IMMUNOLOGY;**;*.*" "/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/**/*.*")))
This part is unnecessary. The call to translate-pathname below doesn't use it.
Now I'm real confused, because without telling the Lisp that "IDO:" is a logical hostname prefix I get:
dada:~/work/abcl$ sbcl This is SBCL 1.0.33, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/IDO:IMMUNOLOGY;"
Which is definitely not what you want, right? Or do you have this translations defined in initialization files (i.e. "~/.sbclrc")?
Erg. That was wrong - meant to edit it out. Sorry.
With the IDO logical pathname host defined with the SETF on LOGICAL-PATHNAME-TRANSLATIONS, I thought you wanted this behavior:
(translate-pathname #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*"
#P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/immunology/"
which is what I observe pre-r12283 ABCL doing.
pre-r12283 ABCL was buggy in a different way. My best understanding is that the behavior observed in sbcl and my patched abcl is correct. -Alan
On 2/3/10 8:22 PM, Alan Ruttenberg wrote: […]
pre-r12283 ABCL was buggy in a different way. My best understanding is that the behavior observed in sbcl and my patched abcl is correct.
Ok, now I think I understand the problem Sorry for the confusion on my part. Your fix [has been committed in r12147][1]. [1]: http://trac.common-lisp.net/armedbear/changeset/12417 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
Hi Mark, On Mon, Jan 18, 2010 at 11:12 AM, Mark Evenson <evenson@panix.com> wrote:
On 1/17/10 11:09 PM, Alan Ruttenberg wrote:
A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more.
e.g.
(TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*")
Used to work, but now fails.
Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS.
In both the released abcl-0.18.0 and trunk (as of r12383), I don't see this bug. getting
CL-USER> (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/IDO:IMMUNOLOGY;"
Could you please provide more information about which version of ABCL has this problem?
Note to developers: the task of determining which version of ABCL people report problems to us would be simplified if we included better versioning wrt. SVN. There is a "version.src" Ant property that is stored in the abcl.jar file to keep track of versions, but when I last looked into it I never found a reasonable way to set it from Ant, as there is no built-in support in Ant for Subversion.
Would be nice to have something like it. Would newer versions (development) come with SVN support built in?
If we could depend on the existence of a 'svn' client binary in the PATH, we could parse its output, but this seems like a bad bet under Windows as a sizable number of people presumably use Explorer Shell extensions like TortoiseSVN.
Which is indeed my case, so I guess our dev community is pretty exemplary :-)
It looks like a possible route would be to parse the contents of '.svn/entries' if it exists to take a stab at reporting which SVN version abcl.jar was built from. Without access to an SVN client we couldn't tell reliably if the source has been modified from that SVN version, but it would give us a decent place to start.
Depending on the contents (or even the existence) of .svn is problematic: the Subversion team is working hard to remove the requirement. On top of that, the contents of the .svn/entries file was changed on every new release from 1.3 on. Should we deliver our source tarballs with some specific properties set up in the properties file in order to make identification easier? The other option would be to grep all source files and put the output of the $Id$ lines in a file in the jar... Bye, Erik.
participants (3)
-
Alan Ruttenberg -
Erik Huelsmann -
Mark Evenson