After mapping the old diff, the next step was to implement the new diff at file as well as directory level and then to implement the opposite operation too, namely the application of a patch. It took me a bit more than a week and there have been even a few iterations on parts of it but the work has been quite satisfying indeed, mainly because I finally got thus to clean all sorts of warts, weirds and workarounds (www!)1 that the original diff and the patch format and all of it really had baked in. Such www as diff preserved unchanged since the 1970s2 are mainly due to limitations - whether of hardware, software or even knowledge - that were indeed very real and relevant 50 years ago but are not all that relevant today anymore. So they got exposed, looked at and discarded as part and parcel of making the new implementation. This is after all exactly what re-implementing something is all about - not just a makeover or mere change of language, nor even just an effective adoption3 but a rejuvenation in a quite direct sense: the old idea is cleaned up of what is not useful or needed or working anymore and gets connected meaningfully to new things so that it can indeed grow again rather than merely exist.
As there is still work to do4 on the remaining bits and parts required for a full SMG-V, I won't attempt just yet a full list of all the cleanups, changes and additions. Nevertheless, I'll share a sneak peek of how a few test runs look at the moment for the part applying a patch and see if you can spot any differences already at this level.
First run on a valid patch and with a correct input to apply on:
./patch_smg test.vpatch tpatch/ STATUS: DELETING file t4/vref.txt STATUS: DELETING file t4/t9/fother.txt STATUS: DELETING file f2.test STATUS: REMOVING dir tpatch/t4/t9 STATUS: REMOVING dir tpatch/t4 STATUS: CREATING dir tpatch/t3 STATUS: MOVING file tpatch/t2/smgv.gpr to tpatch/smgv.gpr STATUS: PATCHING file f1.test STATUS: CREATING new file tpatch/t3/restrict.adc STATUS: CREATING new file tpatch/yet.txt STATUS: CREATING new file tpatch/t2/f1.test
For a taste of basic error reporting, attempting to re-apply that same valid patch only to the *result* of the above patching (hence: the input will not match, of course):
./patch_smg test.vpatch tpatch/ STATUS: DELETING file t4/vref.txt ERROR: Main_Patch: Invalid line no 2 in patch test.vpatch : file "tpatch/t4/vref.txt" does not exist
While there are many different errors waiting to happen at any time, there are also many different checks and reports to help identify the source of any noticed mismatch. Here's only one more example for now, when running on a patch manually messed up with only one tiny change of a single number:
./patch_smg test.vpatch tpatch/ STATUS: DELETING file t4/vref.txt STATUS: DELETING file t4/t9/fother.txt STATUS: DELETING file f2.test STATUS: REMOVING dir tpatch/t4/t9 STATUS: REMOVING dir tpatch/t4 STATUS: CREATING dir tpatch/t3 STATUS: MOVING file tpatch/t2/smgv.gpr to tpatch/smgv.gpr STATUS: PATCHING file f1.test STATUS: CREATING new file tpatch/t3/restrict.adc STATUS: CREATING new file tpatch/yet.txt ERROR: Main_Patch: Invalid line no 284 in patch test.vpatch : Mismatch between hunk's header and the number of added lines to newly created file.
Worth noting perhaps that none of the tmsr vpatch files will pass muster as far as SMG-V is concerned and good riddance. I certainly don't intend to read anything in the old format anymore and there's not going to be any automatic conversion of anything either - at least not under my signature.
The above gives perhaps some hints as to some of the changes in the format of a patch mainly but there are even more significant changes under the hood of it all since the whole point is to finally have V as it's meant to be - not just in parts and name and how the 1970's code might permit. At the moment though, this is all you get to see, since I'm still rather busy with the remaining work and I can't wait to finally have a working V that helps rather than hinders me. Not to mention that all this SMG-V code could really do with some V-versioning of itself, already!
There, while at it, here's this www acronym fixed as well, since the warts, weirds and workarounds looks to me like a much better fit by now than any original worlds and wide and web ideals. ↩
Yes, the original diff was written in the 1970's and that makes it indeed older than myself. ↩
Though even this is quite rare as far as I can tell, probably since it requires first getting to know the old, useful thing and who has the patience for that or something. ↩
Funnily enough, I can't even say that "I was busy and didn't write for more than a week!!" since I wrote actually quite a lot. Only... none of it on the blog and relatively little of it that is not code-related (if not code directly, then comments, notes and discussions about code). ↩
Comments feed: RSS 2.0
Bwahahaha, Weird Warts & Workarounds, now that's a truly fair and balanced backronym if there ever was one! We keep it!
Congrats on the successful regrind. As far as anyone knows, this'd be indeed the first case of old (pre-dotcom) material being regrund into something useful.
Thanks and indeed, Weird Warts & Workarounds rolls even better!
Huh, this might indeed be the first, I hadn't even thought of it. At any rate, I'd certainly be curious to know what other cases there are if anyone knows/thinks of something that might fit the bill.
[...] of the above, VaMP relies on my previous regrind and updated implementation of old Unix's diff and patch as well as the full cryptographic stack that I had implemented for Eulora (a first version of which [...]
[...] done such regrinding previously to software from the 1970s and it enabled the development of very useful tools that pushed quite quickly for further [...]