V11db_gdbm.ztst fails on Cygwin

V11db_gdbm.ztst fails on Cygwin

[Jun T.]

V11db_gdbm.ztst fails on Cygwin as:

./V11db_gdbm.ztst: starting.
--- /tmp/zsh.ztst.2148/ztst.out	2017-03-02 19:26:45.040189100 +0900
+++ /tmp/zsh.ztst.2148/ztst.tout	2017-03-02 19:26:45.055788600 +0900
@@ -1,4 +1,4 @@
-c
-d
 a
 b
+c
+d
Test ./V11db_gdbm.ztst failed: output differs from expected as shown above for:
 ztie -d db/gdbm -f $dbfile dbase
 dbase=( a b c d )
 zuntie dbase
 ztie -d db/gdbm -f $dbfile dbase
 print -rl -- "${(kv)dbase[@]}"
 zuntie dbase
Was testing: replace hash / database, scan
./V11db_gdbm.ztst: test failed.


${(k)dabse} gives 'a c', instead of 'c a' as expeced by the test.

The order the records are visited by gdbm_{firstkey,nextkey}()
depends on the hash values used by gdbm, and (due to some reason
unknown to me) it seems the hash values used on Cygwin are different
from those used on Linux. The gdbm I'm using on Cygwin is from the
Cygwin's package repository (binary distribution).

Is it really necessary to test that gdbm_{firstkey,nextkey}()
gives the same order on different OSs?

PS
On macOS V11db_gdbm.ztst succeeds (with gdbm built by myself from
the gdbm source).

Re: V11db_gdbm.ztst fails on Cygwin

[Sebastian Gniazdowski]

On Thu, Mar 2, 2017, at 02:52 AM, Jun T. wrote:
> @@ -1,4 +1,4 @@
> -c
> -d
>  a
>  b
> +c
> +d
> 
> ${(k)dabse} gives 'a c', instead of 'c a' as expeced by the test.
 
> The order the records are visited by gdbm_{firstkey,nextkey}()
> depends on the hash values used by gdbm, and (due to some reason
> unknown to me) it seems the hash values used on Cygwin are different
> from those used on Linux.
(...)
> Is it really necessary to test that gdbm_{firstkey,nextkey}()
> gives the same order on different OSs?

Was counting on determinism here. A fragile thing, but determinism
should guarantee this. Wonder why Cygwin's gdbm flips order.

Any idea how to write test result so that both hash key orders match?
-- 
  Sebastian Gniazdowski
  psprint3@fastmail.com

Re: V11db_gdbm.ztst fails on Cygwin

[Peter Stephenson]

On Thu, 02 Mar 2017 03:47:40 -0800
Sebastian Gniazdowski <psprint3@fastmail.com> wrote:
> Any idea how to write test result so that both hash key orders match?

The standard zsh test technique would be to put the output into an array
and sort that.

pws

Re: V11db_gdbm.ztst fails on Cygwin

[Daniel Shahaf]

Sebastian Gniazdowski wrote on Thu, Mar 02, 2017 at 03:47:40 -0800:
> Any idea how to write test result so that both hash key orders match?

print -r -- ${(okv)dbase}

Re: V11db_gdbm.ztst fails on Cygwin

[Sebastian Gniazdowski]

On Thu, Mar 2, 2017, at 03:54 AM, Daniel Shahaf wrote:
> Sebastian Gniazdowski wrote on Thu, Mar 02, 2017 at 03:47:40 -0800:
> > Any idea how to write test result so that both hash key orders match?
> 
> print -r -- ${(okv)dbase}
> 

That looks like a new test case, as typical scan, as it looks from the
code, is loop over keys, get their assigned nodes, call func(hnode,
flags). Hashnode contains key. But it might be the same, gathering
key/value done anyway, and then optionally sort on always gathered set,
so maybe that's the answer.

-- 
  Sebastian Gniazdowski
  psprint3@fastmail.com

Re: V11db_gdbm.ztst fails on Cygwin

[Sebastian Gniazdowski]

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

On Thu, Mar 2, 2017, at 02:52 AM, Jun T. wrote:
> V11db_gdbm.ztst fails on Cygwin as:
> 
> ./V11db_gdbm.ztst: starting.
> --- /tmp/zsh.ztst.2148/ztst.out 2017-03-02 19:26:45.040189100 +0900
> +++ /tmp/zsh.ztst.2148/ztst.tout        2017-03-02 19:26:45.055788600
> +0900
> @@ -1,4 +1,4 @@
> -c
> -d
>  a
>  b
> +c
> +d

Patch equips scan tests with sorting via intermediate array, and adds
one new test that does direct (okv).

Also added test of store in forked Zsh. Gdbm supports multiple access if
users take care of locking.
-- 
Sebastian Gniazdowski
psprint3@fastmail.com

[-- Attachment #2: v11db_gdbm_sorted_scan.diff --]
[-- Type: text/plain, Size: 3061 bytes --]

diff --git a/Test/V11db_gdbm.ztst b/Test/V11db_gdbm.ztst
index 486ad48..3531cd1 100644
--- a/Test/V11db_gdbm.ztst
+++ b/Test/V11db_gdbm.ztst
@@ -80,59 +80,60 @@
 >testdata
 
  ztie -r -d db/gdbm -f $dbfile dbase
- print -rl -- "${(kv)dbase[@]}"
+ local -a result=( "${(kv)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie -u dbase
-0:scan read-only tied hash
->testkey
+0:scan read-only tied hash, directly assign local -a
 >testdata
->testkey3
 >testdataxtestdata
+>testkey
+>testkey3
 
  ztie -d db/gdbm -f $dbfile dbase
- local -a arr
- arr=( "${(kv)dbase[@]}" )
- print -rl -- "${arr[@]}"
+ dbase=( a a )
+ print -rl -- "${(kv)dbase[@]}"
  zuntie dbase
-0:different scan, also read-write mode
->testkey
->testdata
->testkey3
->testdataxtestdata
+0:Use scan directly, read-write mode
+>a
+>a
 
  ztie -d db/gdbm -f $dbfile dbase
  dbase=( a b c d )
  zuntie dbase
  ztie -d db/gdbm -f $dbfile dbase
- print -rl -- "${(kv)dbase[@]}"
+ result=( "${(kv)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie dbase
 0:replace hash / database, scan
->c
->d
 >a
 >b
+>c
+>d
 
  ztie -d db/gdbm -f $dbfile dbase
  local -a arr
  arr=( "${dbase[@]}" )
- print -rl -- "${arr[@]}"
+ print -rl -- "${(o)arr[@]}"
  zuntie dbase
 0:scan with no (kv)
->d
 >b
+>d
 
  ztie -d db/gdbm -f $dbfile dbase
- print -rl -- "${(k)dbase[@]}"
+ result=( "${(k)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie dbase
 0:scan with keys only (k)
->c
 >a
+>c
 
  ztie -d db/gdbm -f $dbfile dbase
- print -rl -- "${(v)dbase[@]}"
+ result=( "${(v)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie dbase
 0:scan with keys only explicit (v)
->d
 >b
+>d
 
  rm -f $dbfile
  ztie -r -d db/gdbm -f $dbfile dbase 2>/dev/null
@@ -144,18 +145,21 @@
  zuntie dbase
  ztie -r -d db/gdbm -f $dbfile dbase
  echo $dbase[a]
- print -rl -- "${(kv)dbase[@]}"
+ result=( "${(kv)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie -u dbase
  ztie -d db/gdbm -f $dbfile dbase
  dbase+=( c d )
  echo $dbase[a]
  echo $dbase[c]
- print -rl -- "${(kv)dbase[@]}"
+ result=( "${(kv)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie dbase
  ztie -r -d db/gdbm -f $dbfile dbase
  echo $dbase[a]
  echo $dbase[c]
- print -rl -- "${(kv)dbase[@]}"
+ result=( "${(kv)dbase[@]}" )
+ print -rl -- "${(o)result[@]}"
  zuntie -u dbase
 0:Append with +=( ), also with existing data, also (kv) scan
 >b
@@ -164,16 +168,16 @@
 >b
 >b
 >d
->c
->d
 >a
 >b
->b
->d
 >c
 >d
+>b
+>d
 >a
 >b
+>c
+>d
 
  ztie -d db/gdbm -f $dbfile dbase
  echo ${(t)dbase}
@@ -291,6 +295,13 @@
 >漢字
 
  ztie -d db/gdbm -f $dbfile dbase
+ noglob print -rl ${(okv)dbase[@]}
+ zuntie dbase
+0:Sorted hash scanning and metafication
+>漢字
+>漢字
+
+ ztie -d db/gdbm -f $dbfile dbase
  zgdbmpath dbase
  [[ $REPLY = */Test/db.gdbm ]] && echo correct
  zuntie dbase
@@ -302,6 +313,13 @@
 >correct
 >correct
 
+ ztie -d db/gdbm -f $dbfile dbase
+ fun() { while read line; do echo $line; done }
+ eval "dbase[testkey]=value1" | fun
+ echo $dbase[testkey]
+0:Test store in forked Zsh
+>value1
+
 %clean
 
   rm -f ${dbfile}*

Re: V11db_gdbm.ztst fails on Cygwin

[Jun T.]

On 2017/03/03, at 0:16, Sebastian Gniazdowski <psprint3@fastmail.com> wrote:
> 
> Patch equips scan tests with sorting via intermediate array, and adds
> one new test that does direct (okv).

It now works OK on Cygwin.

Re: V11db_gdbm.ztst fails on Cygwin

[淳一 滝本]

On 2017/03/03, at 0:16, Sebastian Gniazdowski <psprint3@fastmail.com> wrote:
> Patch equips scan tests with sorting via intermediate array

Without the patch, the test fails also on FreeBSD and OpenBSD.
The test passes with the patch, of course.