[armedbear-devel] translate-logical-pathname and :wild-inferiors regression

Erik Huelsmann ehuels at gmail.com
Fri Jan 29 21:00:19 UTC 2010

Hi Mark,

On Mon, Jan 18, 2010 at 11:12 AM, Mark Evenson <evenson at 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.
>> #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
> #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...



More information about the armedbear-devel mailing list