#+TITLE: 2024
#+author: screwlisp
After speaking to prahou and jns, I feel confident in 2024.

In general I am making sure to update my
gopher.club/1/users/screwtape
phront page every time I phlog. I expect to trivially finish
phloggersgarage 100daystooffload, but I guess observing that
will also be nice.

* YEAR THEMES
** Eternal game engine + ECL + CLIM2

in so many words.

*** Eternal game engine by jns

Inhabiting C++ is the most natural useage on the computers everyone
has and can get. Further, ours is a world having sights and sounds.
A world without these mediums is hard to relate to, enter or create.
Eternal game engine, by our own jns fulfills these.

*** Embeddable common lisp

Talking to jns about C++ ECL, I remembered a few ECL idioms. It's
basically not sensible to use ECL contrary to those idioms; or hard
for me at least. In so many words, FFI:C-PROGN. ECL's nature means it
is no programming burden to interleave C++ and lisp. So eternal game
engine is already an idiomatic lisp environment with the caveat that
it's for use on conventional operating systems, targetting freebsd.

*** Common Lisp Interface Manager 2

Since there needs to be an idiomatic lisp interface designed for rich
media, prahou and I chose to use the CLIM2 standard implementation,
MCCLIM. The complication and additional benefit is that the middleware
needs to be connected into eternal as a new backend. This is great,
because it provides a new and especially rich backend for CLIM2 for
everyone to share.

** Second project I leave to prahou to describe

* Minor ("minor") projects

** VHDLISP                                                          :ongoing:

Richness owing from partially adding the VHDL simulation standard to
common lisp continues to astound me. Reading an article about
smalltalk-80, I see it refers to the important built-in simulation
mechanisms, which I think this is. On the other hand, this has made
meeting Alfred M Szmidt's desires in January difficult for me: By
creating a lisp vhdl standard simulation of microcode for the CADR4
with VHDL itself as a side effect, the problem domain becomes to
implement the CADR4 itself in a subset of lisp. On the other hand,
this is nicely metacircular.

** Veilid                                                             :again:

What I learned from my lost-drive veilid implementation where I had
let myself utterly break compatibility with Veilid foundation veilid
was that participating in veilid is actually a cooperation exercise:
NOT to break compatibility and go one's own way. I thought it was
deep. Still going to use ironclad, and I'm going to require UDP
holepunching with I guess usocket. I think the binary format needs to
be wrangled from lisp as lisp.

** Chaosnet over veilid                                            :futurey:

This is a post-veilid concept, but running veilid node chaosnet ethers
seems to allow multi-tenanted multi-homed fully duplexed reliable
(through repitition) communication with some level of cooperative
self-clocking. UDP because the communication is already reliable. The
CADR4 already uses a UDP chaosnet virtual ether.