zsh 5.0.2-test-1 is available

zsh 5.0.2-test-1 is available

[Peter Stephenson]

I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3.
You'll find it at http://www.zsh.org/pub/development or
ftp://ftp.zsh.org/pub/development.

It's also tagged in git as zsh-5.0.2-test-1 if you don't mind building
from scratch.

I don't think anything much configurational has changed recently, so I
hope this won't cause compilation problems.  Please let me know if you
encounter anything unexpected.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: zsh 5.0.2-test-1 is available

[Phil Pennock]

On 2013-11-06 at 20:23 +0000, Peter Stephenson wrote:
> I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3.

ITYM 5.0.3.  :)

> You'll find it at http://www.zsh.org/pub/development or
> ftp://ftp.zsh.org/pub/development.

Built with:
  ./configure --prefix=/opt/zshdev \
    --enable-pcre --enable-cap --enable-multibyte --enable-dynamic \
    --enable-libs="-lncurses" --with-tcsetpgrp DL_EXT=bundle
on MacOS 10.8.5 with XCode 4.6.3; I'm avoiding the newer ones for now,
waiting for 10.9.1, will update XCode then.

(ncurses came from MacPorts, I think)

Compiles cleanly; "make check" runs without issues.

  42 successful test scripts, 0 failures, 0 skipped

-Phil

Re: zsh 5.0.2-test-1 is available

[Axel Beckert]

Hi,

On Wed, Nov 06, 2013 at 08:23:21PM +0000, Peter Stephenson wrote:
> I've uploaded a test version 5.0.2-test-1 prior to releasing 4.0.3.
> You'll find it at http://www.zsh.org/pub/development or
> ftp://ftp.zsh.org/pub/development.
> 
> It's also tagged in git as zsh-5.0.2-test-1 if you don't mind building
> from scratch.

A Debian package based on 5.0.2 packaging plus 5.0.2-test-1 sources
builds fine.

But when using it with my setup, it issues the following error message:

/home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat'

/usr/lib/x86_64-linux-gnu/zsh/5.0.2-test-1/zsh/stat.so exists:
-rw-r--r-- 1 root root 14904 Nov  7 15:09 /usr/lib/x86_64-linux-gnu/zsh/5.0.2-test-1/zsh/stat.so

The corresponding code lines are:

    982 # autoload zsh modules when they are referenced
    983 if is4 ; then
    984     zmodload -a  zsh/stat    zstat
    985     zmodload -a  zsh/zpty    zpty
    986     zmodload -ap zsh/mapfile mapfile
    987 fi

The other two zmodload lines (985 + 986) work fine, only 984 throws
this error reproducibly.

Otherwise zsh 5.0.2-test-1 works fine on a first glance. Will continue
to use it on my development system to see if anything further pops up.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: zsh 5.0.2-test-1 is available

[Peter Stephenson]

On Thu, 07 Nov 2013 16:33:15 +0100
Axel Beckert <abe@deuxchevaux.org> wrote:
> /home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat'

That means the module loaded, but there was already a conflicting
builtin named "zstat" --- at least that's the only likely reason
for that error I can see, unless the builtin table is very badly messed
up.

pws

Re: zsh 5.0.2-test-1 is available

[Phil Pennock]

On 2013-11-07 at 16:05 +0000, Peter Stephenson wrote:
> On Thu, 07 Nov 2013 16:33:15 +0100
> Axel Beckert <abe@deuxchevaux.org> wrote:
> > /home/abe/.zsh/grml-etc-core/etc/zsh/zshrc:zmodload:984: failed to add builtin `zstat'
> 
> That means the module loaded, but there was already a conflicting
> builtin named "zstat" --- at least that's the only likely reason
> for that error I can see, unless the builtin table is very badly messed
> up.

So there is a regression here.

My startup files do:

    zmodload -F zsh/stat b:zstat

With that run, `zmodload` does *not* list the zsh/stat module, in either
5.0.2-test-1 or 5.0.2.

However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it
succeeds silently, but in 5.0.2-test-1 I see the error which Axel
reports.

-Phil

Re: zsh 5.0.2-test-1 is available

[Bart Schaefer]

On Nov 7,  2:18pm, Phil Pennock wrote:
}
} My startup files do:
} 
}     zmodload -F zsh/stat b:zstat
} 
} With that run, `zmodload` does *not* list the zsh/stat module, in either
} 5.0.2-test-1 or 5.0.2.
} 
} However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it
} succeeds silently, but in 5.0.2-test-1 I see the error which Axel
} reports.

I just checked out commit daa828bc51b48110f0a584fa2b74895d2cc761c1 and
compiled it.  I get the same error message in 5.0.2 as in -test-1.

schaefer<501> zmodload -F zsh/stat b:zstat
schaefer<502> zmodload -a zsh/stat zstat
zmodload: failed to add builtin `zstat'
schaefer<503> print $ZSH_VERSION $ZSH_PATCHLEVEL
5.0.2 1.5778

In fact:

burner% zmodload -F zsh/stat b:zstat
burner% zmodload -a zsh/stat zstat
zmodload: failed to add builtin `zstat'
burner% print $ZSH_VERSION $ZSH_PATCHLEVEL
4.3.17 Debian


So I don't know why you weren't getting the error message before, but
it's not a code regression.

Aside:  This is a bit weird:

torch% zmodload -a zsh/stat
zmodload: zsh/stat: `/' is illegal in a builtin

zmodload not checking that it has the correct number of arguments?

-- 
Barton E. Schaefer

Re: zsh 5.0.2-test-1 is available

[Axel Beckert]

Hi,

On Thu, Nov 07, 2013 at 05:36:27PM -0800, Bart Schaefer wrote:
> On Nov 7,  2:18pm, Phil Pennock wrote:
> } My startup files do:
> } 
> }     zmodload -F zsh/stat b:zstat
> } 
> } With that run, `zmodload` does *not* list the zsh/stat module, in either
> } 5.0.2-test-1 or 5.0.2.
> } 
> } However, If I then run `zmodload -a zsh/stat zstat` then in 5.0.2 it
> } succeeds silently, but in 5.0.2-test-1 I see the error which Axel
> } reports.
> 
> I just checked out commit daa828bc51b48110f0a584fa2b74895d2cc761c1 and
> compiled it.  I get the same error message in 5.0.2 as in -test-1.
> 
> schaefer<501> zmodload -F zsh/stat b:zstat
> schaefer<502> zmodload -a zsh/stat zstat
> zmodload: failed to add builtin `zstat'
> schaefer<503> print $ZSH_VERSION $ZSH_PATCHLEVEL
> 5.0.2 1.5778
> 
> In fact:
> 
> burner% zmodload -F zsh/stat b:zstat
> burner% zmodload -a zsh/stat zstat
> zmodload: failed to add builtin `zstat'
> burner% print $ZSH_VERSION $ZSH_PATCHLEVEL
> 4.3.17 Debian

~ → zmodload -F zsh/stat b:zstat
~ → zmodload -a zsh/stat zstat
zmodload: failed to add builtin `zstat'
~ → print $ZSH_VERSION $ZSH_PATCHLEVEL
4.3.10 Debian

Nevertheless I don't get that error message via my zshrc, neither with
4.3.10 (Debian Squeeze/Oldstable), 4.3.17 (Debian Wheezy/Stable) nor
5.0.2 (Debian Sid/Unstable), just 5.0.2-test-1.

> So I don't know why you weren't getting the error message before, but
> it's not a code regression.

I suspect that Phil's and my issues are not as similar as they might
look at a first glance.

Ah "git grep zmodload" over my (well, grml's) zshrc shows:

~/.zsh/grml-etc-core → git grep zmodload
etc/zsh/keephack:zmodload -i zsh/complist
etc/zsh/zshrc:    zmodload zsh/zprof
etc/zsh/zshrc:    zmodload -i zsh/${mod} 2>/dev/null || print "Notice: no ${mod} available :("
etc/zsh/zshrc:    zmodload -a  zsh/stat    zstat
etc/zsh/zshrc:    zmodload -a  zsh/zpty    zpty
etc/zsh/zshrc:    zmodload -ap zsh/mapfile mapfile
usr_share_grml/zsh/functions/Lookup/Backends/LOOKUP_be_rfc:        if ! zmodload zsh/zftp ; then

(Not sure if that helps.)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: zsh 5.0.2-test-1 is available

[Bart Schaefer]

On Nov 8,  4:16am, Axel Beckert wrote:
}
} ~ -> zmodload -F zsh/stat b:zstat
} ~ -> zmodload -a zsh/stat zstat
} zmodload: failed to add builtin `zstat'
} ~ -> print $ZSH_VERSION $ZSH_PATCHLEVEL
} 4.3.10 Debian
} 
} Nevertheless I don't get that error message via my zshrc, neither with
} 4.3.10 (Debian Squeeze/Oldstable), 4.3.17 (Debian Wheezy/Stable) nor
} 5.0.2 (Debian Sid/Unstable), just 5.0.2-test-1.

Hrm.  A look at grml's /etc/zsh/zshrc via github shows that these ...

} etc/zsh/zshrc:    zmodload zsh/zprof
} etc/zsh/zshrc:    zmodload -i zsh/${mod} 2>/dev/null || print "Notice: no ${mod} available :("
} etc/zsh/zshrc:    zmodload -a  zsh/stat    zstat
} etc/zsh/zshrc:    zmodload -a  zsh/zpty    zpty
} etc/zsh/zshrc:    zmodload -ap zsh/mapfile mapfile

... are all protected by a test for "is4", which means they should not be
getting executed by 5.0.2-test-1:

is4(){
    [[ $ZSH_VERSION == <4->* ]] && return 0
    return 1
}

Unless PWS's commit typo of 4.0.x for 5.0.x somehow extended into the
$ZSH_VERSION variable?

Re: zsh 5.0.2-test-1 is available

[Phil Pennock]

On 2013-11-07 at 17:36 -0800, Bart Schaefer wrote:
> So I don't know why you weren't getting the error message before, but
> it's not a code regression.

I apologise, I've tracked it down.  Depending upon the age of a cache
file, zstat might be called at shell startup time.  So it was a race,
which I lost when I tested in 5.0.2-test-1.

In zsh, you can call `zmodload -a zsh/stat zstat` repeatedly without an
error, up until you call `zstat`.  Once `zstat` has been invoked, future
calls to `zmodload -a zsh/stat zstat` will spew an error and return 1.

Unchanged from 5.0.2.

Re: zsh 5.0.2-test-1 is available

[Peter Stephenson]

On Fri, 08 Nov 2013 02:16:27 -0500
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> In zsh, you can call `zmodload -a zsh/stat zstat` repeatedly without an
> error, up until you call `zstat`.  Once `zstat` has been invoked, future
> calls to `zmodload -a zsh/stat zstat` will spew an error and return 1.

Right, that's always how it worked.  I suspect Axel's problem is some
similar clash in startup files; I can't think of another explanation
that makes sense.  A full set -x trace at boot looking for references to
zsh/stat and zstat would probably show.

I think the problem with making this silent is it's not currently
trivial to check that the builtin that's there is actually the same as
the one you're trying to add, so in theory it's not safe to ignore
(though in practice we don't produce modules with conflicting builtins).
It shouldn't be that difficult to do the check properly, though, and
that ought to resolve the issue.

pws

Re: zsh 5.0.2-test-1 is available

[Bart Schaefer]

On Nov 8,  9:38am, Peter Stephenson wrote:
}
} I think the problem with making this silent is it's not currently
} trivial to check that the builtin that's there is actually the same as
} the one you're trying to add, so in theory it's not safe to ignore

If you want to ignore it, "zmodload -ia zsh/stat zstat" works.  I don't
think there's any reason to make -i obsolete in this case.

Re: zsh 5.0.2-test-1 is available

[Peter Stephenson]

On Fri, 08 Nov 2013 06:39:03 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 8,  9:38am, Peter Stephenson wrote:
> }
> } I think the problem with making this silent is it's not currently
> } trivial to check that the builtin that's there is actually the same as
> } the one you're trying to add, so in theory it's not safe to ignore
> 
> If you want to ignore it, "zmodload -ia zsh/stat zstat" works.  I don't
> think there's any reason to make -i obsolete in this case.

Hmmm... the reason is we're getting reports for things that probably
aren't actually bugs, and I for one would rather only get reports for
actual errors.

We removed the need -i from the case of "zmodload zsh/stat" because it's
not an error if zsh/stat gets loaded when zsh/stat is already present.
It seems to me it's equally not an error to mark zstat as a builtin from
zsh/stat if it's already loaded as a builtin from zsh/stat.  It would
only be an error if there's a conflict.

That's how "autoload" works, after all: it can't check for a conflict
(without major faff) but it does check if a function's already loaded.

pws

Re: zsh 5.0.2-test-1 is available

[Bart Schaefer]

On Nov 8,  4:11pm, Peter Stephenson wrote:
}
} It seems to me it's equally not an error to mark zstat as a builtin from
} zsh/stat if it's already loaded as a builtin from zsh/stat.  It would
} only be an error if there's a conflict.
} 
} That's how "autoload" works, after all: it can't check for a conflict
} (without major faff) but it does check if a function's already loaded.


I'm confused; these statements seem contradictory, so I must be missing
something.  If we can't check for a conflict, how can we suppress the
error message?  I.e., how do we know that zstat is already loaded as a
builtin from the same module we're now loading?

Re: zsh 5.0.2-test-1 is available

[John]

On 11/8/13, 7:11 PM, Bart Schaefer wrote:
> On Nov 8,  4:11pm, Peter Stephenson wrote:
> }
> } It seems to me it's equally not an error to mark zstat as a builtin from
> } zsh/stat if it's already loaded as a builtin from zsh/stat.  It would
> } only be an error if there's a conflict.
> }
> } That's how "autoload" works, after all: it can't check for a conflict
> } (without major faff) but it does check if a function's already loaded.
>
>
> I'm confused; these statements seem contradictory, so I must be missing
> something.  If we can't check for a conflict, how can we suppress the
> error message?  I.e., how do we know that zstat is already loaded as a
> builtin from the same module we're now loading?
Could you do something as simple as remember a checksum (or md5sum) and 
maybe the filename when it's loaded?  It seems like that would catch 
everything with a low risk of false matches.

John

Re: zsh 5.0.2-test-1 is available

[Shawn Wilson]

John <jmharres@gmail.com> wrote:
>On 11/8/13, 7:11 PM, Bart Schaefer wrote:
>> On Nov 8,  4:11pm, Peter Stephenson wrote:
>> }
>> } It seems to me it's equally not an error to mark zstat as a builtin
>from
>> } zsh/stat if it's already loaded as a builtin from zsh/stat.  It
>would
>> } only be an error if there's a conflict.
>> }
>> } That's how "autoload" works, after all: it can't check for a
>conflict
>> } (without major faff) but it does check if a function's already
>loaded.
>>
>>
>> I'm confused; these statements seem contradictory, so I must be
>missing
>> something.  If we can't check for a conflict, how can we suppress the
>> error message?  I.e., how do we know that zstat is already loaded as
>a
>> builtin from the same module we're now loading?
>Could you do something as simple as remember a checksum (or md5sum) and
>
>maybe the filename when it's loaded?  It seems like that would catch 
>everything with a low risk of false matches.
>

I think that's overkill. I think giving a return status of 2 or 255 might be sufficient. 

Re: zsh 5.0.2-test-1 is available

[Peter Stephenson]

On Fri, 08 Nov 2013 18:11:43 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 8,  4:11pm, Peter Stephenson wrote:
> }
> } It seems to me it's equally not an error to mark zstat as a builtin from
> } zsh/stat if it's already loaded as a builtin from zsh/stat.  It would
> } only be an error if there's a conflict.
> } 
> } That's how "autoload" works, after all: it can't check for a conflict
> } (without major faff) but it does check if a function's already loaded.
> 
> 
> I'm confused; these statements seem contradictory, so I must be missing
> something.  If we can't check for a conflict, how can we suppress the
> error message?  I.e., how do we know that zstat is already loaded as a
> builtin from the same module we're now loading?

For functions, autoload (the builtin of that name) works this way,
suppressing an error message if a functiona already exists, but it can't
check for a conflict because it would have to scan the path, load the
file it found, and check that the loaded file compared the same as the
already loaded file.  This is as much work as deleting the file and
reloading it when "autoload" is encountered again.  So it silently
assumes if a function is loaded that it's the function you wanted.  I
was using this case as the paradigm of how an autoload of any sort
works, to point out that, when whatever-it-is is already loaded,
generating an error on a new autoload isn't necessarily the right thing to do.

For autoloads from modules, which may be builtins, conditions, math
functions or parameters, we can actually do a bit better, with a little
more work but nothing like to the same extent (no additional loading is
required).  Suppose we load builtin bar from zsh/foo at some point,
doesn't matter how, then run "zmodload -a bar zsh/foo".  We find that a
builtin bar exists.  We can then check that zsh/foo is already loaded,
and is already providing builtin bar.  It seems to me, based on the
argument from functions, that it would be entirely natural just to
ignore the zmodload -a as redundant rather than report it as an error;
and, furthermore, given that you can check by this means the effect really
*is* redundant rather than a conflict, it seems to me there is no
harmful side effect of any sort.  (Obviously, contradictory indications
are invited.)

I hope that's clear now.

I started looking at this on Friday but I need to be careful which
builtins flying around are which, so will get back to it at some point.

pws