* V11db_gdbm.ztst fails on Cygwin @ 2017-03-02 10:52 Jun T. 2017-03-02 11:47 ` Sebastian Gniazdowski 2017-03-02 15:16 ` Sebastian Gniazdowski 0 siblings, 2 replies; 8+ messages in thread From: Jun T. @ 2017-03-02 10:52 UTC (permalink / raw) To: zsh-workers 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). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 10:52 V11db_gdbm.ztst fails on Cygwin Jun T. @ 2017-03-02 11:47 ` Sebastian Gniazdowski 2017-03-02 11:54 ` Peter Stephenson 2017-03-02 11:54 ` Daniel Shahaf 2017-03-02 15:16 ` Sebastian Gniazdowski 1 sibling, 2 replies; 8+ messages in thread From: Sebastian Gniazdowski @ 2017-03-02 11:47 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 11:47 ` Sebastian Gniazdowski @ 2017-03-02 11:54 ` Peter Stephenson 2017-03-02 11:54 ` Daniel Shahaf 1 sibling, 0 replies; 8+ messages in thread From: Peter Stephenson @ 2017-03-02 11:54 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 11:47 ` Sebastian Gniazdowski 2017-03-02 11:54 ` Peter Stephenson @ 2017-03-02 11:54 ` Daniel Shahaf 2017-03-02 12:14 ` Sebastian Gniazdowski 1 sibling, 1 reply; 8+ messages in thread From: Daniel Shahaf @ 2017-03-02 11:54 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: zsh-workers 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} ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 11:54 ` Daniel Shahaf @ 2017-03-02 12:14 ` Sebastian Gniazdowski 0 siblings, 0 replies; 8+ messages in thread From: Sebastian Gniazdowski @ 2017-03-02 12:14 UTC (permalink / raw) To: Daniel Shahaf; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 10:52 V11db_gdbm.ztst fails on Cygwin Jun T. 2017-03-02 11:47 ` Sebastian Gniazdowski @ 2017-03-02 15:16 ` Sebastian Gniazdowski 2017-03-02 23:56 ` Jun T. 2017-03-03 11:06 ` 淳一 滝本 1 sibling, 2 replies; 8+ messages in thread From: Sebastian Gniazdowski @ 2017-03-02 15:16 UTC (permalink / raw) To: zsh-workers [-- 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}* ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 15:16 ` Sebastian Gniazdowski @ 2017-03-02 23:56 ` Jun T. 2017-03-03 11:06 ` 淳一 滝本 1 sibling, 0 replies; 8+ messages in thread From: Jun T. @ 2017-03-02 23:56 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: V11db_gdbm.ztst fails on Cygwin 2017-03-02 15:16 ` Sebastian Gniazdowski 2017-03-02 23:56 ` Jun T. @ 2017-03-03 11:06 ` 淳一 滝本 1 sibling, 0 replies; 8+ messages in thread From: 淳一 滝本 @ 2017-03-03 11:06 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-03-03 12:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-02 10:52 V11db_gdbm.ztst fails on Cygwin Jun T. 2017-03-02 11:47 ` Sebastian Gniazdowski 2017-03-02 11:54 ` Peter Stephenson 2017-03-02 11:54 ` Daniel Shahaf 2017-03-02 12:14 ` Sebastian Gniazdowski 2017-03-02 15:16 ` Sebastian Gniazdowski 2017-03-02 23:56 ` Jun T. 2017-03-03 11:06 ` 淳一 滝本
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).