Comments on: Adventures in the forest of V http://jfxpt.com/2020/adventures-in-the-forest-of-v/ The search for invariants Thu, 09 Apr 2026 22:32:46 +0000 http://polimedia.us hourly 1 By: V in Perl with parsing fix, keksum, and starter, plus the ill-fated vdiff « Fixpoint http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-231 V in Perl with parsing fix, keksum, and starter, plus the ill-fated vdiff « Fixpoint Thu, 02 Apr 2020 17:51:19 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-231 [...] my prior adventures, I reoriented my efforts toward some simpler changes to the v.pl tree, abandoning hopes of a robust [...] [...] my prior adventures, I reoriented my efforts toward some simpler changes to the v.pl tree, abandoning hopes of a robust [...]

]]> By: Jacob Welsh http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-229 Jacob Welsh Thu, 02 Apr 2020 15:21:39 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-229 @whaack, cool. Re III, <a href="http://bvt-trace.net/2020/02/vsh-part-2-ada-utilities/#comment-171" rel="nofollow">discussion with bvt</a> has been illuminating - in brief, the ^diff matching originated with phf's vpatch and so is pretty entrenched, and there are further possible headaches in store for alternative diff implementations. @whaack, cool.

Re III, discussion with bvt has been illuminating - in brief, the ^diff matching originated with phf's vpatch and so is pretty entrenched, and there are further possible headaches in store for alternative diff implementations.

]]> By: whaack http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-228 whaack Wed, 01 Apr 2020 20:08:49 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-228 @jfw I was just pointing out that I had stumbled upon the same "problem" when writing my own version of topological sort for V. At the time I was unaware that the live versions of V in use also had the same quirk; I was speculating that they leveraged the manifest file to work around the inability to revert a file. You have now clarified that the known versions of V don't do this; I don't think I need an example spelled out. @jfw

I was just pointing out that I had stumbled upon the same "problem" when writing my own version of topological sort for V. At the time I was unaware that the live versions of V in use also had the same quirk; I was speculating that they leveraged the manifest file to work around the inability to revert a file. You have now clarified that the known versions of V don't do this; I don't think I need an example spelled out.

]]> By: Jacob Welsh http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-227 Jacob Welsh Wed, 01 Apr 2020 18:30:34 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-227 I suppose I'm OK with the "so don't do that" approach; glad to have it out explicitly though so thank you. It also serves as one concrete reason for a "thou shalt test thy vpatch with a full press before publishing". I suppose I'm OK with the "so don't do that" approach; glad to have it out explicitly though so thank you. It also serves as one concrete reason for a "thou shalt test thy vpatch with a full press before publishing".

]]> By: Stanislav Datskovskiy http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-226 Stanislav Datskovskiy Tue, 31 Mar 2020 22:27:12 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-226 Re #3 -- indeed you had the link. My apologies, missed it on 1st pass. Re IV -- it still isn't clear to me why you would construct a tree where "have the same (path, hash) pair as an output of two different patches in the same VTree". If you end up with such a tree, for whatever reason, it is "coarse error of pilotage". IMHO if you were to make a change to a program but then decided to revert, ought to at least put a comment, "tried $change here, proved fatal" -- rather than bitwise reversion to a previous state. This would be good practice even if V did not exist -- why burn the work that went into testing the unsuccessful change, by not documenting? Re #3 -- indeed you had the link. My apologies, missed it on 1st pass.

Re IV -- it still isn't clear to me why you would construct a tree where "have the same (path, hash) pair as an output of two different patches in the same VTree". If you end up with such a tree, for whatever reason, it is "coarse error of pilotage".

IMHO if you were to make a change to a program but then decided to revert, ought to at least put a comment, "tried $change here, proved fatal" -- rather than bitwise reversion to a previous state. This would be good practice even if V did not exist -- why burn the work that went into testing the unsuccessful change, by not documenting?

]]> By: Jacob Welsh http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-225 Jacob Welsh Tue, 31 Mar 2020 22:04:43 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-225 @Stanislav Datskovskiy: I'm aware of Phf's vdiff, I even described it in the text, you know? You're of course welcome to exclude me from "all known V users" if you like, indeed I admittedly hadn't been dealing with nontrivial trees besides TRB so as to feel a need for a Keccak presser previously. I'm not at all arguing that a cyclic graph should be allowed. The problem in IV occurs even with use of a manifest. (@whaack, do you still think it doesn't? Maybe I need to spell out an example.) @Stanislav Datskovskiy: I'm aware of Phf's vdiff, I even described it in the text, you know? You're of course welcome to exclude me from "all known V users" if you like, indeed I admittedly hadn't been dealing with nontrivial trees besides TRB so as to feel a need for a Keccak presser previously.

I'm not at all arguing that a cyclic graph should be allowed. The problem in IV occurs even with use of a manifest. (@whaack, do you still think it doesn't? Maybe I need to spell out an example.)

]]> By: whaack http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-224 whaack Tue, 31 Mar 2020 20:00:05 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-224 I have mentioned <a href="http://ossasepia.com/2020/04/20/ossasepia-logs-for-17-Oct-2019/#1006780" rel="nofollow">the problem in IV.</a> before when I was discussing a practice V I had written for myself. I have mentioned the problem in IV. before when I was discussing a practice V I had written for myself.

]]> By: Stanislav Datskovskiy http://jfxpt.com/2020/adventures-in-the-forest-of-v/#comment-223 Stanislav Datskovskiy Tue, 31 Mar 2020 19:34:25 +0000 http://fixpoint.welshcomputing.com/?p=112#comment-223 Re: Busybox and "nobody involved with V apparently found this important enough to remedy either" -- AFAIK all known V users currently use <a href="http://barksinthewind.com/2018/vpy-updated-for-vtools/" rel="nofollow">Phf's vdiff</a> or variants thereof, no one is using my original diff/grep/awk-powered one-liner. Re: cyclic graphs: I specifically forbade them in the orig. Vtron. (Observe, there is a detector and eggog.) There is no, AFAIK, up-side to ever having a cyclic patch graph, and plentiful cost (e.g. requires a considerably more complicated "tortoise & hare" toposort, not to mention "wtf, why?!". Consider why chess players are forbidden from repeating a previously-seen board position.) Re: "why V wasn't made to simply include in the header of each patch the hash of its antecedent patch as a whole" : originally didn't have manifest, either. Observe, in Phf's <a href="http://btcbase.org/patches" rel="nofollow">TRB page</a>, a patch was able to have multiple antecedents. Prior to manifest, there was less forced structure, but at the cost of making potentially nonsensical combinations pressable. In 2018 I posted a demo for an <a href="http://therealbitcoin.org/ml/btc-dev/2018-March/000293.html" rel="nofollow">experimental Vtron</a> that would behave as you described. (The algorithm is not mine, but originally Trinque's.) But AFAIK no one tried it. Re: Busybox and "nobody involved with V apparently found this important enough to remedy either" -- AFAIK all known V users currently use Phf's vdiff or variants thereof, no one is using my original diff/grep/awk-powered one-liner.

Re: cyclic graphs: I specifically forbade them in the orig. Vtron. (Observe, there is a detector and eggog.) There is no, AFAIK, up-side to ever having a cyclic patch graph, and plentiful cost (e.g. requires a considerably more complicated "tortoise & hare" toposort, not to mention "wtf, why?!". Consider why chess players are forbidden from repeating a previously-seen board position.)

Re: "why V wasn't made to simply include in the header of each patch the hash of its antecedent patch as a whole" : originally didn't have manifest, either. Observe, in Phf's TRB page, a patch was able to have multiple antecedents. Prior to manifest, there was less forced structure, but at the cost of making potentially nonsensical combinations pressable. In 2018 I posted a demo for an experimental Vtron that would behave as you described. (The algorithm is not mine, but originally Trinque's.) But AFAIK no one tried it.

]]>