You jest, but I did end up doing just that in my implementation (https://github.com/romforth/romforth) trying to shoehorn a Forth implementation into a MSP430 device with just 2KB ROM + 128 byte RAM
Interesting.
I have a slightly off topic question: do you agree that there are no good newbie programming manual for msp430? in comparison to Arduino or PIC etc
Tree Walk Format (TWF) is a flat file format to describe your family tree.
It allows you to describe your family tree in one (or more) files which are editable using your
favorite text editor.
I see it as a viable alternative to GUIs such as Gramps or TUIs such as llines(Lifelines).
Currently it is Unix/Linux only since it uses groff/dot to generate the graph depicting the family tree.
The git repo has a script that turns the flat file you created into a pdf depicting your family tree.
I assume Windows users may be able to use it too using WSL.
It should be possible to generate an equivalent GEDCOM from the TWF input, but that is not implemented yet.
Some additional usage info including examples of family trees from the Bible which are denoted using the TWF
format are available at: https://ces.mataroa.blog/blog/twf_ftwmd
Allow me to brag about romforth (https://github.com/romforth/romforth) which I ported to the "3c" Padauk and can run on really small rom/ram microcontrollers.
Caveats:
- tested only on an emulator SDCC/ucsim_pdk, not on real hardware
- given how small the ram is, there is no user dictionary but new words can be defined and tested using what the Forth folks refer to as "umbilical hosting".
I wanted to run olvwm on Linux (when it went out of support on Ubuntu 16.04) and I'd managed to get this running on Ubuntu 20.04 (and more recently on Gentoo, as documented at https://ces.mataroa.blog/blog/gentoo-olvwm-bye-ubuntu/).
A survey of available olwvm implementations available on github at the time I created the repo is in the README of https://github.com/olvwm/xview/
The "bug" in the counting used here is that the overall Kolmogorov(?)
complexity is not being accounted for because it is shunted elsewhere.
This is true for the other "tinyforth" implementations as well - such as
sectorforth and milliforth, because the actual code ends up in the
"input part of the Turing tape" if you want to think of it that way.
The right way to count it might be to measure the closure of all your
dependencies (in this case, all of the input bytes that are needed plus
the bytes in the BIOS that are needed).
That's what I tought. Even Miliforth lacks a proper complete integer based stack. From that and a few primitives, you can bootstrap a Forth.
On Lisp, Sectorlisp it's interesting; but the ones from https://t3x.org can do far more, even if they are not bootable per se. But T3XForth can, and it's highly usable.
EForth under SUBLEQ it's like that too.
Instead of "Boot sector languages", I'd pursuit a 386 compatbile language being able to fit in a floppy. T3XForth does, and tons more, because the T3X author made eiher standalone ones, or DOS and CP/M 2.2 ports.
I've been faithfully using the same window manager [olvwm] for ~30 years and counting. In fact the decision about which [distro] I pick for daily use is totally dependent on whether it can be coaxed into running [xview]+olvwm.
