IRC channel logs

<oriansj>well I have been maintaining this: https://git.sr.ht/~oriansj/bootstrappable-wiki

<oriansj>i just haven't figured out how to convert markdown into html, gemini and gopher so that our wiki would be available in a more robust fashion.

<theruran>oriansj: pandoc can do Markdown to HTML and plain text. I am sure there are multiple software for converting from Markdown to Gemtext

<theruran>just searching GitHub, https://github.com/Azumabashi/markdown2gemtext and https://github.com/n0x1m/md2gmi

<theruran>or you could probably do it with roff macros :D

<theruran>oh, I think I meant m4

<oriansj>a bit of analysis paralysis I guess but yeah

<oriansj>as I own the https://wiki.bootstrapping.world/ domain and have a server dedicated to running the wiki; my thought was make the wiki be a git repo and do an automatic git pull on a routine basis and give commit access to the git repo to anyone who productively works on the wiki

<oriansj>that way it would be trivial for anyone to fork the wiki going forward and if I go crazy to set up an alternate quickly

<oriansj>I was thinking ikiwiki as that is what the permacomputing community uses or lowdown as it supports a good few options out of the box (and they are both in guix)

<pabs3>ikiwiki on branchable.com also has ways to do anonymous git push, which is nice for wikis

<oriansj>honestly as long as the git history is append-only; in theory anyone should be able to commit

<drakonis>has anyone actually written an assembler using m4?

<muurkha>not that I know of

<muurkha>bitfields are not its strong point

<muurkha>it's more designed to be used as a front end to a simple assembler

<drakonis>i see

<muurkha>it's possible to do I think

<muurkha>Plauger said that one of the worst things he'd done in his life was write a relocating linker in QED, the predecessor to ed

<muurkha>I think that was one of the reasons you can't do that in ed

<drakonis>qed?

<muurkha>and the fact that you could, in theory, write an assembler in m4 (or its predecessor m6, an ASCII version of GPM) is I think a major reason the C preprocessor is so limited

<drakonis>actually

<drakonis>how the heck does that work

<muurkha>which?

<muurkha>what do you mean?

<drakonis>ah apologies, how do you do a relocating linker in QED?

<muurkha>well, I've never used QED, so I don't know what the difficulties were

<muurkha>but in general a linker concatenates like segments, composes a merged symbol table by offsetting some input symbol tables, and then iterates over a list of relocations, performing a fixup for each relocation according to the symbol table and the relocation type and value

<muurkha>and usually whatever value is previously at the location the relocation points to

<muurkha> https://dl.acm.org/doi/10.1145/363848.363863 is the paper describing the original QED. not sure if the Bell Labs version is better-documented than https://www.bell-labs.com/usr/dmr/www/qed.html

<muurkha>but that's probably what Plauger was using, unless my memory is failing me

<muurkha>aha, https://www.bell-labs.com/usr/dmr/www/qedman.html is the manual

<muurkha>hmm, it's amusing that its "regular expression" facility supported matching arbitrary context-free grammars

<muurkha>the Lampson & Deutsch paper has some amusing things to say about bootstrapping

<muurkha>"One of the fundamental requirements for many computer users is some means of creating and altering text, i.e., strings of characters. Such texts are usually programs (...) The most common means of text handling in the last few years has been the punched card deck. (...) the fact that individual cards can be inserted and deleted manually in the middle of a deck has made the keypunch the most

<muurkha>convenient and popular device for text editing.

<muurkha>"With the appearance of online systems, however, in which text is stored permanently within the system and never appears on external storage media, serious competition to the punched card has arisen. Since the online user has no access to his text except through his console and the computer, a program is needed, however minimal, to allow him to create and modify the text. Such a program is called

<muurkha>an *editor* and presupposes a reasonably large and powerful machine equipped with disk or drum storage. The user therefore gains more convenience than even the most elaborate keypunch can provide."

<muurkha>"The original version of the system (...) was designed, written, and debugged by one man in less than a week, and the entire program now occupies less than 4000 words of reentrant code."

<muurkha>which is presumably 4000 instructions, though I could be wrong because I don't recall ever looking at the SDS 930 instruction encoding

<oriansj>4K word leaves plenty of space for a pretty powerful editor as 370 instructions is enough for a basic line editor

<oriansj>(and that is using my *very* bloated assembly code style)

<oriansj>(255 instructions if one uses sloccount)

<stikonas>hmm, I can now build tcc 0.9.26 (or to be more precise mes-tcc on riscv64 though it is a bit crashy and is not able to rebuilt itself)

<stikonas>and at the very least mes/lib/linux/riscv64-mes-gcc/crt1.c has assembly that tcc doesn't understand

IRC channel logs

2023-06-09.log