Since at least December 2017, I've been using for all my code publishing and versioning needs the original implemention of V by mod6 that I even packed and published as a starter kit to help newcomers get over the initial bootstrapping issue - also known as "where to start from with this new V thing!!" The reason for my faithfulness to mod6's old implementation is simply that it's an implementation that has been discussed in quite some detail and has been greatly iterated upon, back when TMSR's 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 implementation, I find myself alternating between the two - while the old v.pl still has its niche for quick deployments on environments lacking GNAT for instance, the increasingly polished vtools is growing on me as a more convenient set of tools in my production environment (where GNAT exists already anyway).

As bvt has been nicely introducing on his own blog each new vpatch through an article of its own, I have been following the code and reading and re-reading his vpatches quite easily. But as it turns out that I haven't yet mirrored the vtools V-tree nor published any of my sigs on its vpatches so far, I'll correct now this oversight and publish them all in one go - at least it should make it even easier to find it all here, I suppose. Moreover, since I took the time to read through all the vpatches again from genesis to the current leaf, I got curious regarding size of vpatches and corresponding net changes to the code too - after all, the vtools V-tree is currently one of the few examples of more advanced use of V: it started with what is effectively a "clean, extract and capture" (by phf) of the diffing utility; it successfuly translated parts from another existing V-tree (e.g. my Keccak implementation from the EuCrypt tree, including further updates and improvements to it, as they became available); it was built upon initially by the original author but then by someone else (bvt) who took over quite smoothly and all for the better really; it received changes and updates that were properly published and discussed as well as otherwise informed by direct feedback and actual use. I guess I could even go on adding to this list but as striking as this might be, it seems to me that the list as it is already makes this vtools V-tree quite unique - not even trb's V-tree can boast having all the above really, as far as I'm aware (and yes, I think it's very unfortunate it can't - perhaps it will and hopefully even sooner rather than later, as it's already quite late indeed, as it is).

All the above out of the way, head over to my Reference Code Shelf for my sigs and my mirror of the full VTools V-tree and otherwise here's a tiny bit of data on vtools' code and changes, in chart and table format, for all preferences:

Overall, reading all vpatches makes for a respectable 13094 lines or otherwise a 523 pages booklet at the standard 25 lines per page. If one read instead only the result of the full press to the final current leaf, that would mean ~8100 lines so about 320 pages instead. Note however that the apparent "gain" might come at a higher cost than you think because reading the vpatches as they are has the advantage of getting to know the code more gradually and therefore having perhaps an easier time at understanding the whole thing (as well as the reasons for it being as it is).

Looking at net changes, the genesis is in this case huge compared to the rest - the reason being that it's a capture of an existing utility. There are otherwise a few clearly longer patches, but they don't always result in a similarly big net change (e.g. vtools_vsh_ada_vfilter.vpatch is 1415 lines itself but since it replaces rather than just adds code, the net change is only +58 lines). Nevertheless, there are precious few patches resulting in a net code reduction - and even then, the net change is quite small. Arguably this can mean of course that the code is already at a very good balance between brevity and clarity. Alternatively, it might simply suggest that unless one aims specifically to reduce the codebase, the chances of this happening naturally are very slim indeed and so the codebase will just keep growing for as long as it keeps changing.

On a different note and looking at the overall length of this "booklet" of code and the total number of 23 vpatches, I kind of wonder as well at which point - or under what circumstances - would it truly be preferable (or even feasible) to regrind and gain clarity (hopefully while reducing the code base too) rather than lose it as natural part of losing at least some of the history of all the changes. Supposedly it's something to find out naturally when such a situation occurs - if ever.

1. From here on, bvt takes over from phf. ↩

Category: Coding, V

Comments feed: RSS 2.0