zsh-users
 help / color / mirror / code / Atom feed
From: Bill Burton <billb@progress.com>
To: Zsh users list <zsh-users@sunsite.dk>
Subject: Re: zsh 4.0.5/4.1.0 release soon?
Date: Thu, 15 Aug 2002 15:28:46 -0400	[thread overview]
Message-ID: <3D5C00EE.E31D18A1@progress.com> (raw)
In-Reply-To: <20942.1028803921@csr.com>

Hello,

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.

-Bill


  reply	other threads:[~2002-08-15 19:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-03 23:35 Kenneth Lareau
2002-08-05  9:43 ` Peter Stephenson
2002-08-06 17:51   ` Kenneth Lareau
2002-08-08 10:52     ` Peter Stephenson
2002-08-15 19:28       ` Bill Burton [this message]
2002-08-15 21:08         ` Felix Rosencrantz
2002-08-16  9:51         ` _ant (was Re: zsh 4.0.5/4.1.0 release soon?) Oliver Kiddle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D5C00EE.E31D18A1@progress.com \
    --to=billb@progress.com \
    --cc=zsh-users@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).