Since I am by far the most experienced user of V, I have therefore also first-hand experience with all the different ways in which *all* implementations of V so far (v.py, v.pl, v.sh & vtools) fail in practice as soon as applied to any production code base with all its complex changes and significantly large sets of vpatches. To keep this short, I'll point out1 just the total deal breakers for me2: the reliance on Koch's gpg, the imposition of arbitrary restrictions due to limitations of various underlying tools imported but not truly adapted to purpose3, combined for maximum damage with a non-existent, utterly and even at times worse than useless approach to "error reporting" that would be better described as "error non-reporting with a dash of retroactive error discovery"4.
None of the above problems have anything to do with the V paradigm itself, of course. They are all simply the problems of the v.py, v.pl and v.sh & vtools implementations and moreover, to be found exactly at the very places where these implementations depart from the V principles. So the cut is clear enough: there's nothing to salvage from the v.py, v.pl and v.sh & vtools. Sure, they have the excuse of being "just drafts", fine. That excuse tends to wear thin after these many years but sure, they are all first drafts at best and as such to be entirely discarded, indeed, so this is exactly what I'm doing, too: I'm discarding them all and I state it here publicly as I owe it to anyone who might read otherwise my equally public previous use of them - they are fine as first drafts and *nothing* more, definitely *not fine* for production use of any sort.
Moving on, I'll implement V for production use as well, with everything adapted to purpose, from cryptography to diff-ing, pressing and everything in between. There's neither need nor any bit of desire to rely on anything that is neither fit for purpose nor adaptable to it and that includes python, perl, gnupg modules of any sort, gpg etc.
Mainly for the benefit of anyone considering using any of these first-draft implementations. Use at your own future inconvenience and for your own future loss. ↩
If you really need more, go ahead and ask me in the comments section. ↩
Such as "can't revert a file" - note that this restriction is simply due to the limitations of the underlying diff that works with file-level hashes, nothing else, despite all the pretense that there is any higher-level reason why such limitation is even desirable. If you really mean that this is a feature and not a bug, go ahead and argue it in the comments but do make sure your argument includes the reason why reverting a function or procedure is at the same time somehow different and perfectly ok. I'll also add that if you really think that one should just know from memory, at vpatch 80 when they remove a function from a file that the result is in fact reverting that file to its version from vpatch 55 then good luck to you, enjoy the toy v implementations and more power to you. ↩
What this means in practice is that you are left to hunt manually for the actual source of the problem and at times this hunt is even potentially extending all the way into the past - you might find out at vpatch 90 that the V-error was introduced... somewhere before, in any of the previous vpatches, aren't you happy to go and search for it in all the tree? For example, v.py will just spit "Cyclic graph" at you and you are welcome to hunt for the 2 vpatches involved and then for the 2 (or more!) files (hashes) involved and so on. V.sh and vtools will construct the vtree correctly by looking at the vpatches as whole units but then will fail at press time because the press still looks at files individually. ↩
Comments feed: RSS 2.0
Adding to the above, from fresh (if basic) testing: while the freshly made smg-diff handles a 2.2G input file without any trouble (and yes, it produces a patch that can just as well be in the same range of size or even larger), vtools' wrapper of my keccak implementation crashes on the same 2.2G input file with "range check failed" exception raised in keccak_c.adb, line 24.
A quick look at the issue in vtools reveals that the wrapper does a direct conversion of the *full input length* of a file from size_t type to Natural type. On a 64-bits machine, size_t is 64 bits indeed but GNAT insists on using 32 bits for Natural (and Integer), so it's no wonder that sort of conversion crashes.
Capu' te doare.
Din categoria "macar asa stii ca-l ai!"
As I notice now that some of the relevant trackbacks didn't quite make it to this article, I'll add them manually to make it easier to follow the trail:
1. For a more detailed discussion of the trouble uncovered here and why it was such a deal breaker, see The State of the (f)Art.
2. For the implementation promised here and fully working just 3 months later, see from It's Called VaMP on.
1 makes for a helpful link indeed for the new (or forgetful old) traveler, and likewise 2 for bridging the otherwise diverging V and VaMP categories, thanks.
Glad to hear it's of use. There's a good point you make on the diverging V and VaMP categories and it hits on that old trouble with ~"pre-assigned fixed categories are not really working" but I don't yet have a fully fleshed out solution for even starting the exploration on better indexing and category assignment and so it's yet another one of those still waiting patiently for its time to come.
[...] kind of lightweight V presser, reducing system requirements and foregoing the generality attempted unsuccessfully by its predecessors in favor of a dead-simple interface and dependable operation on a variety of [...]
[...] ideals that are however practically untenable can literally turn even a valuable concept into a worse than useless software product. Note though that the trouble doesn't stem from *correctness* itself but from a narrow and too [...]