Comments on: v.sh parts 6&7: handling orphans and updated Keccak

By: Mirroring the Vtools V-tree « Ossa Sepia

Mirroring the Vtools V-tree « Ossa Sepia — Fri, 24 Apr 2020 15:17:33 +0000

[...] own public forum worked quite as intended. Nevertheless, as bvt has been dilligently working on owning and improving the vtools suite, clearly communicating on it and on his own history of V use that informs his choices of [...]

By: Diana Coman

Diana Coman — Mon, 20 Apr 2020 11:04:45 +0000

Confirmed it works perfectly now on my machine too, thank you!

I should get around to mirror the whole tree for vtools and publish my sigs for it too, sometime this week.

By: bvt

bvt — Sun, 19 Apr 2020 18:06:29 +0000

Indeed it seems to be gawk-only feature. I have tested your suggested fix with awk 3.1.7, mawk from ~2010, and busybox awk, no problems with any of them. The vpatch is here: curl 'http://bvt-trace.net/vpatches/vtools_vsh_fix_awk.vpatch' > vtools_vsh_fix_awk.vpatch curl 'http://bvt-trace.net/vpatches/vtools_vsh_fix_awk.vpatch.bvt.sig' > vtools_vsh_fix_awk.vpatch.bvt.sig

By: bvt

bvt — Sun, 19 Apr 2020 11:25:50 +0000

Hm, thanks for having a look at this. I will install the same awk version and test the code with it, then see how to best fix it -- most likely using multiple indexes will work out.

By: Diana Coman

Diana Coman — Sun, 19 Apr 2020 10:17:54 +0000

Only now I had a second look at that line where awk complains and I realised that you are possibly trying to use array of arrays? Iirc this is supported only in some versions (gawk but also not older ones) so possibly that's why it fails on my OS. Nevertheless, awk itself allows multiple indices, it just goes array[i,j] (it concatenates them so a sort of inside trick but perfectly fine for needing "several dimensions") - and it usually ends up in shorter code from what I noticed. So looking there, it would be something like dir_ante[$2, n_ante[$2]], perhaps.

By: Diana Coman

Diana Coman — Fri, 17 Apr 2020 09:42:18 +0000

Thanks for the prompt update - confirmed, the new sig works. However, it turns out meanwhile the awk sequence at line 301 in v.sh barfs on my CentOS 6 running GNU Awk 3.1.7, here's the error thrown when running v vtree:

awk: cmd. line:6: FILENAME=="-" && ($1 == "d") {if (!($2 in n_ante)) n_ante[$2] = 0; dir_ante[$2][n_ante[$2]] = $3; n_ante[$2]++;}
awk: cmd. line:6: ^ syntax error
awk: cmd. line:6: FILENAME=="-" && ($1 == "d") {if (!($2 in n_ante)) n_ante[$2] = 0; dir_ante[$2][n_ante[$2]] = $3; n_ante[$2]++;}
awk: cmd. line:6: ^ syntax error
awk: cmd. line:11: level[$2] = max(level[$2], level[dir_ante[$2][i]]+1);
awk: cmd. line:11: ^ syntax error
awk: cmd. line:11: fatal: invalid subscript expression

The rest of commands (I tested briefly patches, wot, flow, antecedents, descendants, press) seem to work fine, at least when tested on vtools' own tree. At a quick first look in the code, I don't know if the trouble might be perhaps a case of that i variable failing to be expanded because of the single quotes for the awk, or similar.

As a side note, now with all the .gpr files to build, I ended up making a "buildall.sh" that just calls gprbuild -P on each of them, as otherwise I *always* seem to forget one!

By: bvt

bvt — Thu, 16 Apr 2020 15:48:12 +0000

Thanks for spotting, I have reuploaded the signature. Seems that as I was writing the article, I uploaded the signature for older version of the vpatch.

By: Diana Coman

Diana Coman — Thu, 16 Apr 2020 14:45:06 +0000

The .sig for vtools_update_keccak.vpatch (aka vtools_update_keccak.vpatch.bvt.sig) doesn't verify for me, not sure how or what might be wrong with my setup (I looked inside both the vpatch and the sig files and they both seem to match the ones linked above so it doesn't seem to be that I got either corrupted on upload):

$ gpg --verify .seals/vtools_update_keccak.vpatch.bvt.sig patches/vtools_update_keccak.vpatch gpg: Signature made Fri 10 Apr 2020 05:03:48 PM BST using RSA key ID 4B962B68 gpg: BAD signature from "bvt aka BT"

By: Diana Coman

Diana Coman — Fri, 10 Apr 2020 17:29:19 +0000

Ha, going from 1.41s to 0.5 is indeed hard to not notice. Looks good at a first read, I'll have to give it another read and a test drive too!