zsh 4.0.5/4.1.0 release soon?

zsh 4.0.5/4.1.0 release soon?

[Kenneth Lareau]

Hello folks,

First off, zsh is a wonderful shell that I've been using for many years now,
and plan to continue using for many years to come. :)

Having just recently upgraded one of my Sun machines to Solaris 9, I note
they're still using zsh 3.0.8, so I'm planning to upgrade... however, the
latest production release, 4.0.4, has been some time ago (nearly a year),
and while I've heard some random comments of a new release soon, nothing
has been said much about it recently... so I thought I'd ask. :)

Is there any hope for a new release, either 4.0.5 or 4.1.0, in the near
future?  Or should I just grab 4.0.4 for now and bide my time? :)

Thanks for any info you can give...

Ken Lareau
elessar@numenor.org

Re: zsh 4.0.5/4.1.0 release soon?

[Peter Stephenson]

Kenneth Lareau wrote:
> Is there any hope for a new release, either 4.0.5 or 4.1.0, in the near
> future?  Or should I just grab 4.0.4 for now and bide my time? :)

4.0.5 has been imminent for some time now, but every time I say I'm
thinking about releasing it, people say, hang on here's a list of other
patches to look at.  It looks like no-one has.  I think it's perfectly
releasable in it's present form, however, so I may be able to sneak it
out while everyone's on holiday.

The target for 4.1.0 was to have the parameter support tidied up.
However, that seems to be receeding into the background, too.  We
really need to draw up a more limited set of goals since at the moment
it looks like nobody's got the time for large scale new code.  There's
plenty of new stuff there in modules and the odd builtin.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh 4.0.5/4.1.0 release soon?

[Kenneth Lareau]

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.

If there's anything I can do to help, I'm willling... though I'll ad-
mit my C is a bit rusty. :)


Ken Lareau
elessar@numenor.org

Re: zsh 4.0.5/4.1.0 release soon?

[Peter Stephenson]

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...)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: zsh 4.0.5/4.1.0 release soon?

[Bill Burton]

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

Re: zsh 4.0.5/4.1.0 release soon?

[Felix Rosencrantz]

--- 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

_ant (was Re: zsh 4.0.5/4.1.0 release soon?)

[Oliver Kiddle]

On 15 Aug, 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

> I should be able to update my existing implementation for the Ant 1.5
> options and submit it early next week.

Felix mentioned that I submitted such a function last week and it does
include the ant 1.5 options. However I don't really know a lot about
ant so it is likely that my function doesn't do the best thing in all
cases and there may well be some aspects of yours that it will be
useful to take. So I suggest that you don't worry about the ant 1.5
options and that we try to take the best from each of our functions.

> 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

Caching is certainly an option. We should be able associate caches with
the appropriate build.xml file though datestamping them would be tricky
unless we load the stat module.

As Felix mentioned, I used sed to get the targets quickly. I don't have
many build.xml files to have tested that on so if anyone could see if it
breaks on any of theirs, that would be useful. It would be easy to
contrive a build.xml to break it but I'd be interested to know if there 
are many other there that break it without trying.

One option would be to use the call-command style (currently only used
for make) to decide between the slow but correct ant solution and the
quick but potentially wrong sed solution.

Also, I've just realised that I forgot to remove the code for completing
the value of $ANT_ARGS from _ant before committing it on the 4.0 branch
so that'll need cleaning up.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.