(DIR) Home
(DIR) == 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:
(HTM) cel/dillo-gopher
(HTM) 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 *that*up.
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.
(DIR) == 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.
(DIR) == 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!
(HTM) Basic Fire Control Mechanisms - Maritime Park Association
(HTM) Basic Fire Control Mechanisms - Historic Naval Ships Association Archive
(DIR) == 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. :')
(HTM) Bootstrapping a line editor under FreeDOS
(HTM) WorldBrain's Memex [doesn't render w/o JS]
(HTM) Netrik Web Browser
(DIR) == 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 ==
(DIR) 2022
(DIR) 2019