/users/aiwein/phlog on sdf.org

	Phlog
	Home

	== 2022-08-15 Dillo's quirks & DPIs for gopher & gemini ==

	Dillo's website has been parked since ~May of this year, its
	development had slowed down considerably and it is probably as
	dead a browser can be, so I'm not sure how many people are
	actually going to write - or bother using - new plugins (DPI)
	for it, but, just in case:

	- it already looks into =~/.dillo/dpi= by default, so there is
	no need to add another =dpi_dir= entry into =~/.dillo/dpidrc=
	(in fact, I'm pretty sure it just reads the first one)
	- it doesn't seem to cope too well with multiple .dpi files in
	any given DPI subdirectory.

	I learned of this when, having installed a second DPI to handle
	=gemini:= links, I decided to not bother with deleting the
	executable, and to just rename it by giving it an =old.= prefix.

	It worked, until I tried using it two days later and it suddenly
	didn't: having closed the dillo instance, dpid - and the
	association between the protocol and the executable - presumably
	went with it, with the error manifesting itself as a series of

	Dpi_get_server_port: can't read server port from dpid.

	lines in the dillo output.

	Fixing it was trivial; figuring out /how/ to fix it, slightly
	less so.

	Incidentally, the DPIs I have been using are Charles E. Lehner's
	=dillo-gopher= and =dillo-gemini=, licensed with GPLv3 and FSF
	All-Permissive License respectively, and available as Git repos
	through Secure Scuttlebutt:
	cel/dillo-gopher
	cel/dillo-gemini

	- - -

	On a slightly different note, I took a stab at revising the
	troff macros I use to generate this phlog (and that I'd also
	like to use to generate a blog/gemlog): I spent five minutes
	adding inline formatting, and wasted the whole afternoon trying
	to figure out how to stop =grohtml= from wrapping its output at
	~64 columns. It's /mostly/ a non-issue, but as I am likely to
	use preformatted text, I'd like to avoid messing thatup.

	I ended up settling on mangling the HTML in post-processing -
	awk to the rescue! - but that's just an ugly hack, one I figure
	I'll have to dig into the grohtml code to fix.

	Or I might just stop forcing troff to do the text formatting.

	Decisions, decisions.

	== 2022-08-01 Update - 2022 ==

	It has been a long time since I last touched this phlog, or
	indeed logged into SDF at all. I had almost forgot about it,
	possibly - probably - because I never got into the habit of
	writing regularly: I'd like to, but it doesn't feel right to
	write about myself, and I don't feel competent enough to write
	about anything else. I know that it is objectively untrue,
	but impostor's syndrome is a right bastard.

	== 2019-11-24 Hardware archeology - Mechanical computing mechanisms ==

	A long, long time ago - possibly more than a decade - I stumbled
	across an old manual on mechanical computers, which were used
	for fire control systems back in the forties.

	I changed my laptop at least twice since, and even if I
	probably still have that file, I have no idea where that might
	be.

	Today, I found it again, almost by accident, when clicking on a
	Wikipedia link gave me the magic words I needed for Google to
	find it again: it was /Basic Fire Control Mechanisms/, OP 1140,
	from 1944, and it's available online from at least two
	locations.

	I can barely wrap my head around the basic components described
	in Section 2, and they are of course impressively impractical,
	but also fascinating. Need to implement the trigonometric
	functions in hardware? Just cut the right groove into a cam!
	And don't worry if your computer is starting to look like a
	dieselpunk torture devices, those are just multipliers and
	integrators!

	Basic Fire Control Mechanisms - Maritime Park Association
	Basic Fire Control Mechanisms - Historic Naval Ships Association Archive

	== 2019-07-01 Musings on browser history ==

	Today, I spent quite a bit of time looking for a web page that I
	stumbled across back in 2017, detailing how the author
	bootstrapped their own (line) editor under FreeDOS by ECHOing
	Pascal code to a file, one line at a time. It was nothing
	groundbreaking, but interesting, and, no matter what I did, I
	could. Not. Find. It.

	I tried looking at my Firefox history for that time period - my
	old profile is still hanging around - but nada. I tried
	googling - well, Startpage'ing - for it, using multiple
	different sets of keywords, but nada.

	In the end, I found that page in one of my old bookmarks file.
	I would have never found it again had I not saved it: neither
	the title nor the URL contained any of the keywords I searched
	for (ed, editor, edlin, pascal, scratch), and they were not at
	all descriptive of its contents.

	Once more, I found myself wishing that web browsers would save
	the text of the pages we browse. They wouldn't even need to
	index them, or to save the HTML, let alone any of the auxiliary
	resources needed to render them - JS-only pages can pretty much
	get bent, even if snapshotting the DOM is an option - but just
	having them save the text would be incredibly useful.

	To be fair, there has been some progress in this area, with at
	least one web-extension for this - WorldBrain's Memex -
	existing, but... I also wish browsers were uncoupled enough for
	this to be doable with a few lines of code.

	The netrik web browser (which died a long time ago), for
	example, never implemented support for HTTPS, and the author was
	considering just letting wget or curl take care of it, with
	netrik only handling the rendering of the HTML itself: it would
	be even more interesting if the rendering was a completely
	separate program, taking in a tree of "widgets" from the parser
	- HTML/CSS, normally, but potentially replaceable to handle any
	other reasonable similar document layout format.

	Troff, maybe. :')

	Bootstrapping a line editor under FreeDOS
	WorldBrain's Memex [doesn't render w/o JS]
	Netrik Web Browser

	== 2019-06-26 Restructuring the phlog - part 3 ==

	I started restructuring my phlog a few days ago, and today I
	finished it.

	I don't have to create the folder structure by hand anymore, nor
	I have to write the gophermaps myself: a small set of groff
	macros is taking care of that, together with a small Python
	script which iterates over the post files, invoking troff as
	needed, creating the folders, and generating the archives.

	I update the root gophermap (which contains the text of the
	latest post) with a short ed script, which looks for two
	markers, `# latest - start' and `# latest - end', deletes all
	the lines between them, and adds the text of the latest post
	(which my Python script conveniently leaves in a `latest'
	gophermap in a format amenable to inclusion).

	I spent way too much time for my tastes on this, as I had to
	debug a few issues that popped up because I'm used to the GNU
	versions of the various tools I used (sed, shell, even ed).

	A few things I learned:

	- the NetBSD version of ed doesn't have comments (#), and its
	read command (r ...) either doesn't do tilde expansion or
	doesn't follow symlinks. I solved the former issue by
	shelling out for the comments (very inefficient, but I
	really don't want to leave ed scripts lying around
	uncommented - they might try to take over the world or some
	such), and the latter by reading not from a file, but from
	the output of a cat invocation.
	- the NetBSD version of sed doesn't have character escapes for
	the replacements (e.g., you can't do s/@@/\t/), so you need
	to insert the raw characters in there, and it also expects
	the file parameter to be passed after its options (e.g.,
	-i, -e '...').


	== Archive ==
	2022
	2019