1973 Short Film Arcology: City in the Image of Man.

https://slrpnk.net/post/25144826

Ah, the beautiful potential and cautionary tale of arcologies. I could flip through the images of Soleri for hours. Hello Future Me does a nice, bite-sized overview of the artist, architect and urban planner coined the term and refined the concept. More information in replies.

https://www.youtube.com/watch?v=4_FMiHUvtBM

#arcology #architecture #solarpunk #cyberpunk

Mistigram: a vignette of a do(o)med arcology, “Everything’s Fine In Here” is a specimen of #TypewriterArt from the desk of @lordnkon that raises a lot of questions seemingly answered by its title. (What’s up with the dome? What’s with the apparently smoldering rubble comprising roughly two thirds of your dome’s contents? Blink twice if you need help!) This piece was included in last month’s science fiction-themed MIST0524 artpack collection.

https://mistfunk.wordpress.com/2024/06/09/mist0524-ldn-everythingsfineinhere/

#arcology #dome #LordNikon #MIST0524 #typewriterArt #typewriterart

A few weeks ago I wrote an ArroyoAtomHandler which would go over each element to generate a page, sort of like the built-in org exporters or my Arroyo HTML exporter. It was bodgy as hell, and I probably could have done a better job at it, but it was just too easy to get confused in working between the Atom and the HTML exporter, and I just didn't like it.

So yesterday I took The Arroyo HTML exporter and gave it the ability to only export a few headings, based on an allowlist of IDs passed in to it.

I also extended the system to cache the contents of Headings' PROPERTIES drawers, in both The Parser Heading Type, and the Arcology Org-Roam Caching Models which can drive other behaviors. I've given the Arcology the same metadata-query powers for Headings which it already has for Pages. This allows me to, at minimum, capture the publish date of any Heading in my system and then query those. The Arcology captures these dates, converts them in to DateTime objects which can then be used to group and order posts, do time-bound queries, and the like, and this can be extended to other metadata stored on the Headings.

Combining these two things together lets the Arcology populate feeds from anywhere in my notebooks as in the Atom Feed Handler. This code design is way more reasonable to deal with and more flexible than the ArroyoAtomHandler was.

So soon I can microblog from my org-mode journal and knowledge system by generating private, topic-specific Atom feeds which automatically cross-post to my Fediverse profiles via Feediverse or a built-in implementation. I can confidently generate a private journal feed that doesn’t have an HTML-page counterpart, it’s just an atom feed of a selection of my org-mode system work1.

I'm pretty close to having this in a position where it can be deployed. I think largely the behavior and features won't change except for some small design cues, but it's not quite feature complete yet. I laid out a Rough Timeline and Task List on the Arcology's repo which will spell out a "1.0".

I've been planning in earnest to ship a "1.0" version of the Arcology publishing platform and the Complete Computer dynamic declarative environment this year. Part of that is re-structuring all these components so that the Arcology and the Complete Computer can be more piece-meal assemblies that others could adopt without pulling in all of my frankly inane software preferences. As part of that, I want to produce a series of video tutorials as a set of documentation, which I have been calling Rebuild of The Complete Computer. I don't have much to share yet on that front, but a plan is coming together.

The Rebuild of the Complete Computer series will be a semi-scripted stream series where I sell and document the org-mode publishing, computing, and productivity suite I’ve developed for myself and my community.

The current design of these sites is fine, but the way I differentiate the sites using certain emoji for each domain makes the site a bit too busy for my taste. I will not stop using Vulf Fonts, and this design carries that forward. What happens now is that each cross-domain link is tinted with the background of the page it'll link to. So if you browse the sites enough, you'll identify where you are based on the coloring at the top. Each site is stored in the DB along with a link color that is set by the Arcology Seed Command and a Django view renders a dynamically generated CSS file and because I've been more and more of an org-babel sicko, those CSS files are paired with one for the current page's site are generated dynamically using org-mode tables. 😈

I also set up a flexbox layout that will show the backlinks and page metadata on the side on a wide enough display, or float them toward the bottom if you're on a narrow display or browsing on mobile. I'm still investigating what changes I need to make to get Tufte-CSS-style sidenotes to work, but this is a good start.

I need to tackle feed generation next, and I am not looking forward to re-doing this to not rely on Pandoc like the current version does. Once I've done that, it can be self-hosting though, which is exciting stuff.

This fall I have been spending more time with the experimental rust rewrite of my Arroyo Systems Management libraries, the early promising progress was written about below in I am starting to experiment with a rust rewrite of the Arroyo Arcology Generator. Since then, quite a lot of progress has been made.

I spent most of this summer building a few prototypes to try out different ORMs and compare them to what exists in the current Arcology FastAPI application, which uses a library called SQLModel which promises the best of Pydantic for validation and marshaling and SQLAlchemy for query and persistence. It's fine, but a bit overkill for what I ended up building. I spent some time prototyping the Arcology's data model with a few different Rust and Python ORMs before landing on a surprising best choice:

The next version of the Arcology will be built with Django: Meet The Arcology Project: Django Edition

I spent some time over the last year building a small application for the Data Rights Protocol in Django with a coworker who had prior experience with it. I had used it a bit in back in maybe 2012 but never really gave it a fair shake. While there was a lot I didn't and don't like about the codebase we built for testing DRP, Django is really decent to work with once you internalize a project structure and start to work with the ORM. While I haven't had to optimize the ORM's behavior or individual queries in anger yet, it's transparent, it's robust, and it was really easy to get the data model I wanted slotted in to place. Compared to most of the Rust ORMs which involved code generation or a large amount of boilerplate entity structures or trait implementations, this felt more akin to writing Rails or SQLModel. Only Elixir/Phoenix's Ecto came close, and while I thought hard about shipping this in Elixir, I ended up deciding not to based on the agility I have had in the Django prototype.

Ultimately, I'm coming to appreciate Django a lot more than I did a year ago. It's a good kit and I could become quite productive with it. The latest versions have some async python3 support which I tried to use for a bit but ultimately want to rip out since the ORM has two incompatible query paths between sync/async and you can't mix them, so you end up with multiple implementations of the same getter/setter with different colored functions that don't compose. But that's python. Based on historical traffic patterns, Arcology can handle running inside a handful of gunicorn processes. Hell it could run inside of 1 most of the time!

So Django handles page routing, templating, statics, and the data model that is used to serve pages. The data model and the actual HTML generation are being handled by the Rust codebase. pyo3 and its maturin build tool are hot shit. that thing fucking slaps. it goes so hard. etc. It makes it really easy to expose Rust code to Python and the reverse, too.

In The arroyors Native Org Parser the Orgize parser turns a page in to a struct of keywords, headings, links, etc, and these are shepharded in to Python and persisted in to the DB by Django.

This allowed me to do some thing cool very quickly: The The Complete Computing Environment configurations are now generated by the Django codebase instead of Emacs Lisp, and it's faster and more robust. I can nix run a flake to generate the DB from a directory of org-mode files and run it again to tangle them in to a init.el. Soon enough you could, too. It even runs in t184256/nix-on-droid so I can make config changes to my server or emacs environment and rebuild it on the go [not that i should…. 😛]

The arroyors Native Org Parser also has a fairly basic Org to HTML exporter built in to it, extending functionality in Orgize to provide an HTML exporter that, in a single pass, does all the work which the FastAPI process had to do in three steps. And it does so without invoking Pandoc.

The most complicated part as always is the URL rewriting from internal org-roam IDs to external URLs like the one you're reading right now.

Consider a link to this very post [[id:20231223T231032.979299]]: find the file this heading is stored in. See if that file has a page entity, this will have an ARCOLOGY_KEY keyword in it, publishing it to an arbitrary domain/path in my system, in this case arcology/updates. arcology maps to a domain, engine.arcology.garden. this is replaced to generate a URL to this page, and then the ID is added as an anchor to jump the viewer to this post's headline. it's complicated but it keeps me from having to maintain file system heirarchies and just lean on org-roam's linking facilities in a flat file layout. And as of today The Arcology Project: Django Edition supports rendering these URLs:

There is still a laundry-list of feature work and basic functionality to be done and this system is a long way still from being able to replace the existing system but the new codebase already reveals some very nice synergies.

Speaking of synergies, I have one last thing to share, the new system will Ingest files on-demand using Syncthing rather than inotify as I hinted at in the last post. This, along with much much faster ingestion, means that the sites will update within seconds of a change being made on an endpoint. Syncthing basically provides a very robust HTTP long-poll wrapper around inotify and i would love to not deal with temporary files and POSIX semantics and shitty state machines like I did in the Arcology Automated Database Builder for the FastAPI site. swimmingy.