2024-12-12 00:01:46 I made a variable-width font editor for the ZX Spectrum https://github.com/Veltas/spectrum-env/blob/master/font-orig.asm 2024-12-12 00:02:30 Which I use as a benchmark, because a lot of editors running on modern hardware run choppier than this 2024-12-12 00:04:22 there can be lots of layers these days 2024-12-12 00:13:07 I think that for framebuffer manipulation you probably want guarantees stronger than "completes in finite time" 2024-12-12 00:14:20 I think you want a guarantee of "doesn't hang the display for more than a millisecond", which probably means being able to suspend the drawing computation and resume it later after user interaction. that, in turn, probably requires some kind of transactional memory to avoid graphical glitches 2024-12-12 00:14:46 BPF and Bitcoin Script can make such absolute guarantees because they have no subroutines and no backward jumps 2024-12-12 00:19:47 Well this is interesting 2024-12-12 00:20:09 I just installed mlterm because it has support for variable-width fonts 2024-12-12 00:22:22 https://i.imgur.com/qZRfTvW.png 2024-12-12 00:24:39 lseek() allows C programs to do relative seeks on potentially unbounded read/write files, so you can implement a Turing machine that way. A thing I'm not clear about is whether C requires the capacity of each memory location to be bounded. Could you maybe just store an arbitrary-precision integer in each memory location, and address memory by using those arbitrary-precision integers as pointers? 2024-12-12 00:26:38 thanks for the link on Gordon Letwin's post! 2024-12-12 00:26:47 hmm, too bad Zarutian is offline 2024-12-12 00:30:59 I have some ideas about text terminal protocols that support proportional fonts in a reasonable way. I suspect I can make them *simpler* than the nightmare alphabet soup that is the VT100 escape sequence repertoire. but I haven't tried them out yet, so I don't know yet 2024-12-12 00:30:59 I don't doubt 2024-12-12 00:31:14 And Forth is a good way to control this, in my opinion! 2024-12-12 00:31:17 yes 2024-12-12 00:31:36 i'm obviously lacking context, but what's the motivation for using lseek(2) (and i'm assuming a subsequent read(2)) in this case vs. mmap(2) and mapped access via a pointer? 2024-12-12 00:31:59 one key idea is nested table layout: making all cells in the same column the same width, which is the minimum width required to hold all of their contents, and similarly for the heights of all cells in a row 2024-12-12 00:32:09 I'm hoping to write some text drawing stuff at some point, when my Forth is working properly 2024-12-12 00:32:32 I'll start with the variable width bitmap font I made for the spectrum though 2024-12-12 00:32:38 another key idea is cursor addressing by saving marks and sending the cursor to a saved mark rather than by row number and column number 2024-12-12 00:32:48 unjust: oh, we were talking about whether fixed-size pointers made C non-Turing-complete 2024-12-12 00:34:01 my argument here is that lseek() with SEEK_CUR on a read-write file (plus read() and write() — or the stdio equivalents, fseek(), fread(), and fwrite()) makes C Turing-complete even if its pointers are quite small indeed 2024-12-12 00:34:18 veltas: I'm excited to see it! 2024-12-12 00:34:35 Yeah the file functions in C were literally designed with tape in mind 2024-12-12 00:34:58 rewind() ftw 2024-12-12 00:35:41 I'm not sure to what extent the /dev/mtX and /dev/rmtX devices on early Unix were seekable to arbitrary byte positions 2024-12-12 00:36:11 but certainly magtape was at least a very strong inspiration 2024-12-12 00:39:42 unjust: does that make sense? 2024-12-12 00:39:56 veltas: how are you liking mlterm? 2024-12-12 00:43:42 that screenshot makes me think that irssi wants each line in the main chat area to be a separate two-column table (timestamp and username on the left, one or more chat lines on the right), and the screen as a whole to be a four-row table whose second row contains all the visible chat lines nested in it and whose first row (the topic) is prevented from increasing the layout width (hiding the horizontal 2024-12-12 00:43:48 overflow) 2024-12-12 00:43:56 xentrac: i guess it does. is the tape length limit (due to posix specifying that off_t should be a signed integer type) an issue at all? 2024-12-12 00:44:41 unjust: I don't think so, because I don't think it's illegal to have a longer tape than off_t can address directly 2024-12-12 00:45:53 I did something vaguely similar in http://canonical.org/~kragen/sw/dev3/alglayout.py, where I'm using infinite repetition with truncated overflow for things like dot leaders and ASCII-art separators 2024-12-12 00:48:30 in that case I was rendering the abstract layout for a fixed-width ASCII terminal, but I think you could render exactly the same layout for a device supporting proportional fonts; you'd just have to query the font metrics when you were doing it. here's a six-line sample: 2024-12-12 00:48:34 * ======================================================================== 2024-12-12 00:48:36 - |Chapters Page| 2024-12-12 00:48:39 * |----------------------------------------------------------------------| 2024-12-12 00:48:41 | 0.|The unchained desert of the singing perfume. . . . . . . 1| 2024-12-12 00:48:44 * | 1.|La brisa ilusa de la neblina abandonada. . . . . . . . 43| 2024-12-12 00:48:46 - | 2.|The smiling murder within her young daughters. . . . . . 80| 2024-12-12 00:50:53 that layout is specified with the following code, of which the above sample shows everything except the final "dhr", double horizontal rule: 2024-12-12 00:50:53 vr, hr, dhr = [~String(s) for s in '|-='] 2024-12-12 00:51:29 I suspect that in Forth the way to do this would be to define each of those variables as a colon definition which calls layout words to nest and unnest 2024-12-12 00:51:51 sort of like IMGUI 2024-12-12 10:52:20 xentrac: Stopped using mlterm 2024-12-12 10:52:40 Also that length limit is mlterm, not vim, although vim would probably cause the same issue 2024-12-12 10:53:00 Or irssi rather 2024-12-12 10:53:13 But because terminals are assumed to be fixed width it doesn't really work 2024-12-12 10:53:23 We can solve this in Forth, anyway 2024-12-12 14:13:57 It's probably good to take inspiration from drawing software like QuickDraw and GDI 2024-12-12 16:19:24 veltas: yeah, if you don't have character cells you need a non-character-cell way to specify layout 2024-12-12 22:08:04 xentrac: I'm also thinking about pic macro system for troff 2024-12-12 22:08:27 Basically use a lot of globals, probably have some way to push/pop 'pen'/font state 2024-12-12 22:08:49 a rich set of words for changing direction etc 2024-12-12 22:17:08 roff macros can modify macros for extra fun