Re: zsh 4.0.5/4.1.0 release soon?

[Felix Rosencrantz <f_rosencrantz@yahoo.com>]

--- Bill Burton <billb@progress.com> wrote:
> Don't know this is worth waiting for, but I've written support for the
> Jakarta Ant build tool (http://jakarta.apache.org/ant/) using the new
> completion system.  Since then, a newer version of Ant (1.5) has just been
> released so I need to add support for a few new command line options.  The
> completion support seems to work well with the exception that it doesn't
> cache the targets and their descriptions in the build file.  As a result,
> there are slight delays during completion as ant -projecthelp is run each
> time completion is requested.
> 
> I should be able to update my existing implementation for the Ant 1.5
> options and submit it early next week.

Oliver just submitted such a function less than a week ago:
	http://www.zsh.org/mla/workers/2002/msg01057.html
I believe it includes the 1.5 changes.

> If anyone has any suggestions or examples that would be helpful in
> implementing caching, that would be appreciated.  The simple approach I
> was considering was to save the path and timestamp of the build file along
> with the targets and their associated descriptions as variables in
> memory.  If either the path to the build file changed or the timestamp of
> the one on disk changed, the build file would be reevaluated and cached. 
> With this approach, only one Ant project at a time can be supported in a
> given shell process without having to reevaluate the build file.  I don't
> see that as a big limitation for most uses.


Zsh already has some basic support for caching, look at the zshcompsys
man page for the functions:  _store_cache   _retrieve_cache _cache_invalid
You can implement any type of caching policy with
this system, since you have to provide a function that determines
whether or not your cache is current or not.  For examples, look at the
shipping completion functions for the caching functions:
	_apt _deb_packages _perl_modules _rpm _urpmi

Oliver's completion function does not attempt to cache the target
names.  Instead it uses a sed script to extract target names, which
is not always correct.  Plus, it doesn't get the descriptions.
The advantage of this though is that it is fast, it is current,
and can deal with multiple build.xml files.

I use ant, and have to deal with multiple build.xml files.  So
having a single cache for ant would be problematic for me.

I believe, though I may be wrong, the zsh cache functions are not
particularly good at dealing with the fact that you would want to
create a cache on a per file basis.  You can provide a tag name,
which is used as a filename to hold your cached data.  So it's not
easy to create a tag based on an existing pathname, you would need
to create some directory structure in the cache directory, before
using the tag.

It would be great if the cache functions could make it easy to create
per file caches, (e.g. one per build.xml file).  This would also be very
useful for _java_class, which looks through jar files.  In my environment
I have some jar files that are static and others that more dynamic.
So per jar or build.xml file caches would be nice.

-FR.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com