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.