As I mentioned before, I have written a V presser before starting v.sh, and not mentioning a word about it was a kind of debt on my side. So this article will provide a retrospective on the vy.scm, as it was called. I will not focus so much on the internals of the tool itself, but rather share some thoughts about its development and the implementation language.
I started writing vy.scm in ~2018 shortly before joining the TMSR, as the first tool to actually get access to the TRB sources in the pressed form, from practical point of view, and in general because I appreciated the simplicity and elegance of V. At that point, I was working through Starting Forth/Thinking Forth textbooks1, and really liked one aspect of Forth: because Forth is so simple to implement, everyone has his own implementation tuned to ones needs. This, however, makes code sharing impossible - in spite of the ANSI standard, there are always enough incompatibilities, for example in the dictionary implementation, so its the ideas that are shared instead; the developers interested in actually putting them to use can fit these ideas into their Forth as they wish.
This was the underlying implementation philosophy for vy.scm. Instead of looking at how v.pl/v.py worked inside, I looked at the vtree structure on the file system, looked at vpatches, read the description of V in Ben Vulpes' blog, and implemented it by relying only on the aforementioned sources2. This necessarily meant that the functionality that others may have relied on was dropped, as the general expectation was that everyone who cares to use V would implement the tools with all the functionality that he wishes to have. Upon some forced reflection, this approach does not strike me as particularly sane.
What I was blind to when starting writing vy.scm was that while implementing a simplest presser is a day of work, the time necessary to implement an actually useful program is much bigger, at least for me. So going too far with this development approach too far means that anyone who wishes to start using V, must now be stuck for a few weeks figuring out how to implement some basic piece of software anew. IMO this stresses the need of standardization: at the time of starting a blog, I did not even consider an option of a static blog, or any other platform. I knew that the standard blog engine was MP-WP, and this is what was there to use, it was not even a matter of "wanted" or "needed". Among pressers, no implementation has received a blessing that strong.
Another aspect of vy.scm implementation is the language: while "scm" file extension hints that it was implemented in Scheme, this is not exactly true. I implemented it in Scheme Shell3, in which I was interested because it looked like a viable language for reliable scripting: it had subprocess management facilities that are below (but close to) a pain limit that distinguished a shell from a programming language, it had the data structures that shell lacked, it had better scoping rules - what's not to like?
Not to like, as it turned out, were: an implementation of a size worthy of a full-scale language (~4Mb worth of sources, IIRC) and usability of a scripting language: there is a upper limit to memory allocated by scsh, that can be reliably changed only by re-bootstrapping the scsh image from its host Scheme48, it has no copy-on-write for strings, meaning that I had to implement an interning table to take care of the vpatch headers4. Another issue is that the original (i.e. working) scsh is 32-bit only, and runs on the old Scheme48. And so while Scheme48 was updated to 64-bit version in meantime, scsh was verschlimmbessert into working-but-not-quite state: it boots to the prompt, however some functions present in the original version are not exported, and these minor incompatibilities are all over the system. The practical consequence is that you're stuck with one of the two incompatible versions of system, depending on what versions was packed by the maintainers, or a mess on your hands that's too big to fix. So in the end, I kept vy.scm only on the "main battle tank^W^Wmachine", and used vk.pl on all remote servers.
Some of my conclusions out of this experience:
- Standardization: saves everyone resources that are best spent on something more useful. I can see why not aiming for it can kill organizations.
- Fits-in-head: the sources of scsh were too big for me to fix quickly, while scsh was not good enough to continue using. This was one of the motivations for starting v.sh.
- Scripting: it is better to use shit-and-sticks that Unix provides (because you're stuck with it anyway), than go for exotic tools with unmaintainable and unmaintained runtimes. IMO the programming language to kill the shell is still not there.
The sources for those interested (archaeologists):
curl http://bvt-trace.net/vpatches/vy-genesis.vpatch > vy-genesis.vpatch
curl http://bvt-trace.net/vpatches/vy-genesis.vpatch.bvt.sig > vy-genesis.vpatch.bvt.sig
curl http://bvt-trace.net/vpatches/vy-2.vpatch > vy-2.vpatch
curl http://bvt-trace.net/vpatches/vy-2.vpatch.bvt.sig > vy-2.vpatch.bvt.sig
- Thinking Forth is a nice read independent of the programming language you use. [↩]
- I did grep out the gpg invocations from v.pl. [↩]
- A modified R5RS Scheme written as an extension/modification of Scheme48. [↩]
- I was blind at the time to the option of just (intern)'ing all of them. I was aware that this option exists, but I found it unclean and unappealing at that time. Looking back, I think it was wrong, and I should have taken the "unclean" option: this would saved a small but non-negligible amount of time and lines of code. [↩]