From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17465 invoked from network); 15 Aug 2002 21:09:01 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 15 Aug 2002 21:09:01 -0000 Received: (qmail 26224 invoked by alias); 15 Aug 2002 21:08:47 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5250 Received: (qmail 26207 invoked from network); 15 Aug 2002 21:08:46 -0000 Message-ID: <20020815210844.43239.qmail@web10402.mail.yahoo.com> Date: Thu, 15 Aug 2002 14:08:44 -0700 (PDT) From: Felix Rosencrantz Subject: Re: zsh 4.0.5/4.1.0 release soon? To: Bill Burton , Zsh users list In-Reply-To: <3D5C00EE.E31D18A1@progress.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Bill Burton 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