Zsh Mailing List Archive
Messages sorted by:
Re: zsh 4.0.5/4.1.0 release soon?
- X-seq: zsh-users 5247
- From: Bill Burton <billb@xxxxxxxxxxxx>
- To: Zsh users list <zsh-users@xxxxxxxxxx>
- Subject: Re: zsh 4.0.5/4.1.0 release soon?
- Date: Thu, 15 Aug 2002 15:28:46 -0400
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Organization: Progress Software Corporation
- References: <20942.1028803921@xxxxxxx>
Peter Stephenson wrote:
> Kenneth Lareau wrote:
> > Thanks for the replies on the current release situation, though after
> > reading them I'm still uncertain as to whether the next release is
> > around the corner or not. :) I don't mind holding off for a week or
> > so, but also don't mind installing 4.0.4 right now if 4.0.5/4.1.0 is
> > at least another month or two out. Just wondering if there's an idea
> > which might be more likely.
> 4.0.5 is more likely. I'll try and do it in the next few days before I
> go away for a week. Does anyone definitely have something useful worth
> waiting for? (Vague hopes are no longer enough...)
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.
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.
Messages sorted by: