A superficial review of Nathan Froyd's CL diff

July 24, 2022 by Lucian Mogosanu

This article is part of a series on eating the Unix world using Lisp. If you're not genuinely interested in the subject, then you're more than welcome to fuck off.

Since the recent discussions on Lisp and V, I've decided to review (or re-re-re-review, rather?) Esthlos' Common Lisp Vtron1. I've only stopped halfway because I observed that while Esthlos-V comes with a Keccak2 implemented in Common Lisp, it completely relies on GPG for crypto on one hand3, and it completely lacks a vdiff utility on the other. And while the existing vdiff is a completely honest and sane implementation, it itself relies on a working Ada compiler, which I haven't tried building for years, while its maintainer has gone silent and his site is meanwhile gone from the interwebs. Before you ask, I do have some static GNAT binaries lying around from the old days, but... since I'm here and I've declared my inclination towards Lisps, I guess it couldn't hurt to take a cursory look at whatever the interwebs, as broken as they find themselves, have on display in terms of "diff" implementations in Common Lisp.

So far the only CL diff implementation that I've found was written by one Nathan Froyd4. It seems to have been abandoned about a decade ago, although it's not complete, that is, it has a "diff" utility but no inverse ("patch") operation. I've tested the implementation on small examples and as far as I can tell it does the job. Moreover, the code is fairly well documented, readable and entirely ready to be completed and extended towards a complete vdiff/vpatch duo. I'm not too sure of the dependency on trivial-gray-streams and cl-ppcre, but that's nothing new, is it?

So I suppose I'll play a bit more with this and if I don't find any serious issues with it within the next... few months, I guess, I'll probably make a genesis and sign it. Then I will first cut the multi-format support out5, integrate Esthlos' Keccak and then I'll add V patch support, which, along with Esthlos' thing should make for a more or less complete V kit for the Common Lisp user.

At least that's the plan -- let's see how it goes.


  1. Quoth myself:

    In 99.99% of cases when you read about "V" in some TMSR-related context, the text doesn't refer to any particular implementation of a version control system, but rather first and foremost to a particular set of methods for doing version control.

    Which isn't to say that there wasn't a term used to refer to a particular implementation of V. Most commonly, when you see the word "Vtron" somewhere, that's exactly what it refers to. The only Common Lisp Vtron that I'm aware of was written by one Esthlos, going by the meatworld handle of Andrew Erlanger. His blog is meanwhile gone from the interwebs, but his implementation remains mirrored on my web, among others.

    And to bear witness to the intellectual strength of the meanwhile gone Republic, the reader may simply head over to Stan's logger and write "from:esthlos", and lo! Esthlos' entire history of public replies will unfold before the reader's eyes.

    Sure, maybe it ain't much, but it's certainly hundreds of miles above what today's democracy has on offer. 

  2. In most V implementations, the hash function used for uniquely identifying files in V patches. 

  3. I guess this couldn't be helped, could it? I went pretty much the same way back in my early days. 

  4. I don't know him, but he seems to have written, among others, a crypto library (also discussed in the old logs), a (de)compresser, a binary-ASCII {en,de}coder and a few other Lisp usefuls. Meanwhile he seems to have moved on to stuff such as Rust, so I guess he won't mind if I steal his code.

    And if he does, well... he can voice his complaints in the comment box at the bottom of this page. 

  5. The initial V implementations were only designed to support the unified diff format, although in principle other formats are possible, sure -- as with the previously-mentioned Keccak, this is an implementation detail. Still, if you want to support e.g. binary diffs, you'd better carve them out of the genesis yourself, I for one don't see any reason to keep them all in one place. As far as my own work using V is concerned, at least for the time being -uNr is not only the default, it's the only possible alternative. 

Filed under: lisp.
RSS 2.0 feed. Comment. Send trackback.

4 Responses to “A superficial review of Nathan Froyd's CL diff”

  1. mirror of ave1's www, if someone needed : http://dulap.xyz/pub/mirrors/ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/

    (there's similarly http://dulap.xyz/pub/mirrors/qntra.net/ , http://dulap.xyz/pub/mirrors/bvt-trace.net/ )

  2. #2:
    spyked says:

    Thanks, Stan! I'll pull that and mirror it myself sometime.

    If I remember correctly, Ave1's scripts also downloaded some (many?) dependencies from GitHub, I'm not sure if those are yet available anywhere. Do you happen to have them mirrored?

  3. http://nosuchlabs.com/pub/gnatdeps/ ; AFAIK that's all of them.

  4. [...] all practical points of view. I rarely read or write any Latin nowadays, even less often than I do Lisp. Lisp is for the most part useless to me in my day-to-day activities, yet I spend some of my time [...]

Leave a Reply