This section is an update:

I "accidentally" put a deadline on the JonesForth port recently. I want to finish off a bunch of the little projects I’ve accrued for myself this year so I can more single-mindedly focus on a few bigger ones going into the next year. Well, as soon as I had that deadline, you know what happened? I started trying to hurry through blocks of JonesForth assembly, converting them to NASM as fast as I could. Stupid, right?

I knew I had to force myself slow down. But that’s easier said than done. A sense of urgency is easily gained, but not so easily lost.

My "shower epiphany" last night (this is days after writing this original article), was how to go about slowing down. And here it is: I’m going to stop where I’m at in the translation, fix any syntax errors so the thing assembles, and then walk through every single instruction I’ve got so far and make sure it all works as expected. And to make that more enjoyable and actually have something to show for my efforts when I’m done, I’m going to log the whole session. I don’t even have X on this computer, so the obvious choice for logging is GNU Screen, the terminal multiplexer.

My first thought was, oh great, now I have to learn another tool and get completely sidetracked!

Then my second thought was, hold on, that is great. Now I can finally learn another big ubiquitous GNU application properly and have another tool I’m confident using. Plus, I think Screen will be useful for all kinds of convenience improvements: I’m currently using Linux’s virtual terminals (Alt-F1, Alt-F2, etc.) to have a Vim session and GDB session both open for easy reference. I have to manage those manually. With Screen, I’m pretty sure I can automate opening both things with a single command and then be able to toggle between them with Screen’s Ctrl-a, Ctrl-a.

So I’m currently reading the entire GNU Screen User’s Manual and trying it all out so I know what my options are. Then I’m going to log a big old GDB session and turn it into a transcript which can go into the repo as another artifact on the journey. Now I’m imagining a series of brief session transcripts in which I explore each new bit of functionality. I think this will be really neat.

(Update: I’m doing this! Check out the log files in the repo as mentioned above.)

The point is, I sort of lost my way for a moment, thinking of the finished Forth port as the "point" of this exercise. It’s not. The learning process and the skills I acquire are the point. Plus, after the port is done, Assembly Nights are going to turn into Forth Nights. I’ve got Leo Brodie’s Starting Forth and Thinking Forth on my nightstand. So this journey will take however long it takes and it will be glorious.