zsh 5.0.8.-test-3

zsh 5.0.8.-test-3

[Peter Stephenson]

I've uploaded 5.0.8-test-3 to

http://www.zsh.org/pub/development/

The changes from 5.0.8.-test-2 are mostly minor; the most significant
fixed testing using zpty on OpenBSD, thanks to Jun.

If you have a not very common operating system, please try this out;
otherwise, 5.1 should be fit to release.

pws

Re: zsh 5.0.8.-test-3

[Baptiste Daroussin]

2015-08-25 20:48 GMT+02:00 Peter Stephenson <p.w.stephenson@ntlworld.com>:
> I've uploaded 5.0.8-test-3 to
>
> http://www.zsh.org/pub/development/
>
> The changes from 5.0.8.-test-2 are mostly minor; the most significant
> fixed testing using zpty on OpenBSD, thanks to Jun.
>
> If you have a not very common operating system, please try this out;
> otherwise, 5.1 should be fit to release.
>
> pws

Test passes perfectly on FreeBSD

Best regards,
Bapt

Re: zsh 5.0.8.-test-3

[Danek Duvall]

On Tue, Aug 25, 2015 at 07:48:07PM +0100, Peter Stephenson wrote:

> I've uploaded 5.0.8-test-3 to
> 
> http://www.zsh.org/pub/development/
> 
> The changes from 5.0.8.-test-2 are mostly minor; the most significant
> fixed testing using zpty on OpenBSD, thanks to Jun.
> 
> If you have a not very common operating system, please try this out;
> otherwise, 5.1 should be fit to release.

I'm getting the following failure on Solaris (12):

    *** /tmp/zsh.ztst.out.28050     Tue Aug 25 12:45:19 2015
    --- /tmp/zsh.ztst.tout.28050    Tue Aug 25 12:45:19 2015
    ***************
    *** 1,4 ****
      THURSDAY
    !    JANUARY
      090
      1
    --- 1,4 ----
      THURSDAY
    ! %^_10B
      090
      1
    Test ./V09datetime.ztst failed: output differs from expected as shown above for:
      if [[ $skip_extensions = 1 ]]; then
	ZTST_skip="strftime extensions not supported"
      else
	(
	  strftime '%#A' 0
	  strftime '%^_10B' 0
	  strftime %03Ey 650000000
	  strftime %-Oe 0
	)
      fi
    Was testing: various extensions
    ./V09datetime.ztst: test failed.

Any ideas?  Perhaps this particular set of strftime expandos aren't
supported on Solaris.

Thanks,
Danek

Re: zsh 5.0.8.-test-3

[Mikael Magnusson]

On Wed, Aug 26, 2015 at 12:22 AM, Danek Duvall <duvall@comfychair.org> wrote:
> On Tue, Aug 25, 2015 at 07:48:07PM +0100, Peter Stephenson wrote:
>
>> I've uploaded 5.0.8-test-3 to
>>
>> http://www.zsh.org/pub/development/
>>
>> The changes from 5.0.8.-test-2 are mostly minor; the most significant
>> fixed testing using zpty on OpenBSD, thanks to Jun.
>>
>> If you have a not very common operating system, please try this out;
>> otherwise, 5.1 should be fit to release.
>
> I'm getting the following failure on Solaris (12):
>
>     *** /tmp/zsh.ztst.out.28050     Tue Aug 25 12:45:19 2015
>     --- /tmp/zsh.ztst.tout.28050    Tue Aug 25 12:45:19 2015
>     ***************
>     *** 1,4 ****
>       THURSDAY
>     !    JANUARY
>       090
>       1
>     --- 1,4 ----
>       THURSDAY
>     ! %^_10B
>       090
>       1
>     Test ./V09datetime.ztst failed: output differs from expected as shown above for:
>       if [[ $skip_extensions = 1 ]]; then
>         ZTST_skip="strftime extensions not supported"
>       else
>         (
>           strftime '%#A' 0
>           strftime '%^_10B' 0
>           strftime %03Ey 650000000
>           strftime %-Oe 0
>         )
>       fi
>     Was testing: various extensions
>     ./V09datetime.ztst: test failed.
>
> Any ideas?  Perhaps this particular set of strftime expandos aren't
> supported on Solaris.

So it seems. I don't have access to any obscure operating systems so I
just guessed that if someone supported one extension, they'd support
all of them. The one we test to see if we should skip the test is just
zero-padding though which is pretty easy/obvious to implement. I guess
we can check that one instead / as well. It looks like it supports
both # and E too, so those wouldn't do the trick.

diff --git i/Test/V09datetime.ztst w/Test/V09datetime.ztst
index c935199..902fc6f 100644
--- i/Test/V09datetime.ztst
+++ w/Test/V09datetime.ztst
@@ -8,7 +8,7 @@
   unset LC_ALL
   LC_TIME=C
   TZ=UTC+0
-  [[ "$(strftime %04y 1)" = "0070" ]] || skip_extensions=1
+  [[ "$(strftime %^_10B 0)" = "   JANUARY" ]] || skip_extensions=1
   [[ "$(LC_TIME=ja_JP.UTF-8 strftime %OS 1)" = 一 ]] || skip_japanese=1

 %test

Now the question is if someone supports that one, but not the others
:). (If we try all of them and skip the test, the test approaches
being sort of pointless, except we can notice it was skipped on a
glibc system and realize something is wrong in our parsing.)

-- 
Mikael Magnusson

Re: zsh 5.0.8.-test-3

[Danek Duvall]

On Wed, Aug 26, 2015 at 01:09:07AM +0200, Mikael Magnusson wrote:

> >           strftime '%#A' 0
> >           strftime '%^_10B' 0
> >           strftime %03Ey 650000000
> >           strftime %-Oe 0
>
> [ ... ]
>
> So it seems. I don't have access to any obscure operating systems

Obscure?  <sigh>

I know, I know.

> so I
> just guessed that if someone supported one extension, they'd support
> all of them. The one we test to see if we should skip the test is just
> zero-padding though which is pretty easy/obvious to implement. I guess
> we can check that one instead / as well. It looks like it supports
> both # and E too, so those wouldn't do the trick.

FWIW, we do have our man pages online:

    http://docs.oracle.com/cd/E36784_01/html/E36874/strftime-3c.html

which documents # and E and O, as well as ^ and _.  So I don't know why it
didn't work, unless the underlying implementation is broken, which is
entirely possible (and likely enough that I'd say you should just keep the
test as it is and I'll go make sure the appropriate bug is filed and just
live with the test failure for now).

Still, it seems like the test should be able to distinguish between broken
zsh code and broken system code.  Or not really care about what extensions
the implementation supports, if everything is just a system-dependent
passthrough.

Thanks,
Danek

Re: zsh 5.0.8.-test-3

[Mikael Magnusson]

On Wed, Aug 26, 2015 at 3:27 AM, Danek Duvall <duvall@comfychair.org> wrote:
> On Wed, Aug 26, 2015 at 01:09:07AM +0200, Mikael Magnusson wrote:
>
>> >           strftime '%#A' 0
>> >           strftime '%^_10B' 0
>> >           strftime %03Ey 650000000
>> >           strftime %-Oe 0
>>
>> [ ... ]
>>
>> So it seems. I don't have access to any obscure operating systems
>
> Obscure?  <sigh>
>
> I know, I know.

I was just kidding, read it as "operating systems that aren't Linux" :).

>> so I
>> just guessed that if someone supported one extension, they'd support
>> all of them. The one we test to see if we should skip the test is just
>> zero-padding though which is pretty easy/obvious to implement. I guess
>> we can check that one instead / as well. It looks like it supports
>> both # and E too, so those wouldn't do the trick.
>
> FWIW, we do have our man pages online:
>
>     http://docs.oracle.com/cd/E36784_01/html/E36874/strftime-3c.html
>
> which documents # and E and O, as well as ^ and _.  So I don't know why it
> didn't work, unless the underlying implementation is broken, which is
> entirely possible (and likely enough that I'd say you should just keep the
> test as it is and I'll go make sure the appropriate bug is filed and just
> live with the test failure for now).

I'll let Peter decide which of those to do then.

FWIW glibc has some fun bugs/quirks too, (%EA isn't specified to do anything)
% date +%014EA
00000000%014EA

> Still, it seems like the test should be able to distinguish between broken
> zsh code and broken system code.  Or not really care about what extensions
> the implementation supports, if everything is just a system-dependent
> passthrough.

Well, it's a bit hard to tell, the output would be the same in both
cases (depending on how broken the zsh code got).

-- 
Mikael Magnusson

Re: zsh 5.0.8.-test-3

[Peter Stephenson]

On Wed, 26 Aug 2015 04:19:45 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> > FWIW, we do have our man pages online:
> >
> >     http://docs.oracle.com/cd/E36784_01/html/E36874/strftime-3c.html
> >
> > which documents # and E and O, as well as ^ and _.  So I don't know why it
> > didn't work, unless the underlying implementation is broken, which is
> > entirely possible (and likely enough that I'd say you should just keep the
> > test as it is and I'll go make sure the appropriate bug is filed and just
> > live with the test failure for now).
> 
> I'll let Peter decide which of those to do then.

It's minor enough that I'm not *that* bothered.

I have a vague prejudice that releasing something with a test failing,
even if it's a "real" failure, is going to cause more trouble than it's
worth for something that's not a core part of the shell and which is new
anyway.  Suppose we apply the test patch now and back it off immediately
after the release?  The released code is still capable of showing the
problem, so this don't make debugging harder.

pws

-- 
Peter Stephenson | Principal Engineer Samsung Cambridge Solution Centre
Email: p.stephenson@samsung.com | Phone: +44 1223 434724 |
www.samsung.com

Re: zsh 5.0.8.-test-3

[Mikael Magnusson]

On Wed, Aug 26, 2015 at 10:48 AM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Wed, 26 Aug 2015 04:19:45 +0200
> Mikael Magnusson <mikachu@gmail.com> wrote:
>> > FWIW, we do have our man pages online:
>> >
>> >     http://docs.oracle.com/cd/E36784_01/html/E36874/strftime-3c.html
>> >
>> > which documents # and E and O, as well as ^ and _.  So I don't know why it
>> > didn't work, unless the underlying implementation is broken, which is
>> > entirely possible (and likely enough that I'd say you should just keep the
>> > test as it is and I'll go make sure the appropriate bug is filed and just
>> > live with the test failure for now).
>>
>> I'll let Peter decide which of those to do then.
>
> It's minor enough that I'm not *that* bothered.
>
> I have a vague prejudice that releasing something with a test failing,
> even if it's a "real" failure, is going to cause more trouble than it's
> worth for something that's not a core part of the shell and which is new
> anyway.  Suppose we apply the test patch now and back it off immediately
> after the release?  The released code is still capable of showing the
> problem, so this don't make debugging harder.

That sounds reasonable to me.

-- 
Mikael Magnusson

Re: zsh 5.0.8.-test-3

[Peter Stephenson]

On Wed, 26 Aug 2015 11:30:46 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> > I have a vague prejudice that releasing something with a test failing,
> > even if it's a "real" failure, is going to cause more trouble than it's
> > worth for something that's not a core part of the shell and which is new
> > anyway.  Suppose we apply the test patch now and back it off immediately
> > after the release?  The released code is still capable of showing the
> > problem, so this don't make debugging harder.
> 
> That sounds reasonable to me.

I've applied this change for now.

I intend to make a release some time over the weekend unless someone
comes up with something major.  (I'm not going away for the bank holiday
week following, so this isn't a traditional time for a release, but
it'll do.)

pws

Re: zsh 5.0.8.-test-3

[Michael Beasley]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]


    
Compiles and works great on OS X 10.10.5

-------- Original message --------
From: Baptiste Daroussin <baptiste.daroussin@gmail.com> 
Date: 08/25/2015  5:57 PM  (GMT-05:00) 
To: Peter Stephenson <p.w.stephenson@ntlworld.com> 
Cc: Zsh Users <zsh-users@zsh.org> 
Subject: Re: zsh 5.0.8.-test-3 

2015-08-25 20:48 GMT+02:00 Peter Stephenson <p.w.stephenson@ntlworld.com>:
> I've uploaded 5.0.8-test-3 to
>
> http://www.zsh.org/pub/development/
>
> The changes from 5.0.8.-test-2 are mostly minor; the most significant
> fixed testing using zpty on OpenBSD, thanks to Jun.
>
> If you have a not very common operating system, please try this out;
> otherwise, 5.1 should be fit to release.
>
> pws

Test passes perfectly on FreeBSD

Best regards,
Bapt