Differences

This shows you the differences between two versions of the page.

--- newsletters:2025-03 [2025/04/01 02:09] – [folk2] osnr
+++ newsletters:2025-03 [2025/04/01 20:40] (current) – discord
@@ Line 28: / Line 28: @@
     * {{newsletters:folk-shapes-tuneup.gif?0x200}} {{newsletters:folk-shapes-tuneup-text-large.jpeg?0x200}}
   * (Andrés) Dot detector — not much progress this month, will get to it early April
-  * (Mason) [[https://github.com/FolkComputer/folk/pull/198|Basic program grouping]] — a program that runs a list of programs, even if they're not visible (it helps with saving table space as programs accumulate, I like stacking the programs below the group!)
+  * ([[https://github.com/smj-edison|Mason Jones]]) [[https://github.com/FolkComputer/folk/pull/198|Basic program grouping]] — a program that runs a list of programs, even if they're not visible (it helps with saving table space as programs accumulate, I like stacking the programs below the group!)
 ==== Folk gadget & QR scanner ====
@@ Line 166: / Line 166: @@
 (//and// it's a correctness improvement -- it means we should be able to draw text non-distorted in the real world, not relying on the projector pixel grid as we do now.)
-Broke up the Vulkan gpu.folk more cleanly into gpu.folk, gpu/images.folk, and a new gpu/writable-images.folk. (Had to improve C import/extend technology so we could access the gpu C code from the other modules.)
+Broke up the Vulkan gpu.folk more cleanly into gpu.folk, gpu/images.folk, and a new gpu/writable-images.folk. (Had to improve C import/extend technology so we could access the gpu C code from the other modules -- you can even use global variables from another module now, at least by a ''_ptr()'' getter I added. Had to figure out the right Vulkan render pass and image format stuff so we can still have single pipelines that we reuse across both image-target and screen-target draw operations.)
 Made more of the operations run concurrently (and in arbitrary threads) in normal Whens instead of one big GPU loop, which should make the system more robust (and mean that stuff like new-shader compilation doesn't freeze the whole system) (and let others extend it further in Folk modules and get access to state that's just stored in statements instead of loop-local variables), but does mean we need more locking and fences and semaphores and stuff to synchronize the GPU actions.
 It's cool to think about how much draw logic can be implemented using idiomatic Folk constructs, and it's a good test of how expressive we can make Folk.
+Lots of weird images like this to test drawing in an image and then drawing that image onto the screen:
+{{:newsletters:pasted:20250401-021250.png?350px}}
+(here, was also encountering a bug with line drawing that turned out to be that I forgot about triangle facing / vertex order.)
 === Laptop universe and safety concerns ===
@@ Line 176: / Line 182: @@
 I've been testing a lot on my laptop, which has produced some side quests:
-  * Brought back [[https://github.com/FolkComputer/folk/blob/4c96d35cf1e6fa35aaac5bf37cebb3126ef78331/virtual-programs/fswatch.folk|hot swap]] so you can live-edit even pretty deep virtual programs on laptop (needed this to debug GPU texture stuff more easily, be able to mess around)
+  * Brought back [[https://github.com/FolkComputer/folk/blob/4c96d35cf1e6fa35aaac5bf37cebb3126ef78331/virtual-programs/fswatch.folk|hot swap]] so you can live-edit even pretty deep virtual programs on laptop (needed this to debug GPU texture stuff more easily, turn off draw operations, mess around with coordinate transforms until it was correct)
+    * (isn't it cool that this can just be a blocking infinite loop now, because folk2 supports that? no need to think about the event loop or use ''readable'' or anything)
   * New version of ''exit()'' -- I'm calling it ''__conclude'' -- so we can write tests that terminate cleanly, so I can test the whole writable-image flow more easily.
+  * New finalizer concept so we can release GPU resources in statements safely?
+    * {{newsletters:imag11e.png?300px}}
+These all have a similar energy: they both are part of a whole constellation of safety concerns I have about Folk programs. Basically, a Folk program needs to be cancelable, it needs to be hot-swappable (that is, you retract it, clean up all its stuff, then assert a new version of it that presumably wants to do a lot of the same things). That's a pretty high bar! [[https://social.omar.website/@omar/statuses/01JQM63EE1NKSZM5R7W8SCW4G1|Unix can do it with processes]], but we want to share more state than Unix processes do. How do you release all the resources cleanly, do it in the right order, etc?
+Another class of issue is queueing issues, where a thread (usually the sysmon thread) freezes and the rest of the system gets overrun by clock events and/or garbage and crashes:
+{{:newsletters:pasted:20250401-021357.png?450px}}
-These two have a similar energy: they both are part of a whole constellation of safety concerns I have about Folk programs. Basically, a Folk program needs to be cancelable, it needs to be hot-swappable (that is, you retract it, clean up all its stuff, then assert a new version of it that presumably wants to do a lot of the same things). That's a pretty high bar! [[https://social.omar.website/@omar/statuses/01JQM63EE1NKSZM5R7W8SCW4G1|Unix can do it with processes]], but we want to share more state than Unix processes do. How do you release all the resources cleanly, do it in the right order, etc?
 === Inter-thread shared objects ===
 (I still don't know if we'll merge this, but) I've been noodling some more on the concept of inter-thread shared objects (see [[newsletters/2025-02#shared-immutable-immortal-objects|last month]]), so we don't have to copy and reparse (or cache-lookup) term objects every time we use a statement in a different thread.
+I've been trying an approach from last month (which does feel actually-implementable) where we only /temporarily/ shimmer objects if they're inter-thread-shared, which only requires some pretty mechanical changes to all the shimmering functions in the Jim Tcl interpreter.
 {{newsletters:c66f2b55-c5e0-4d2d-8560-12ec42f861bc-22511-0000170b2cd6a9d0.png?400px}}
-There are so many trade-offs (now shimmering is just temporary for shared objects, now we have to track lots more stuff, etc) that I don't know if it's worth it compared to the current folk2 approach of just caching everything. Hmmmm.
+But there are so many trade-offs (now shimmering is just temporary for shared objects, now we have to track lots more stuff, etc) that I don't know if it's worth it compared to the current folk2 approach of just caching everything. Hmmmm.
 == Mason's dive into not shimmering shared objects ==
@@ Line 195: / Line 211: @@
 ==== Outreach and other systems ====
-  * [[https://github.com/smj-edison|Mason Jones]] updated the [[https://folk.computer/supercollider|SuperCollider instructions]] to make booting up more consistent:
+  * Mason updated the [[https://folk.computer/supercollider|SuperCollider instructions]] to make booting up more consistent:
     * {{newsletters:screenshot-2025-03-31-at-5.17.34 pm.png?400px}}
   * Mason and [[https://x.com/_rpf|Rob Fielding]] discussed wanting scrolling in the editor, how to edit printed programs, and physical debugging tools.
@@ Line 204: / Line 220: @@
   * Rob got an AAXA 4K1 projector and used it to fashion his own Folk lamp:
     * {{newsletters:img_9691.jpg?0x250}}{{newsletters:img_9685.jpg?0x250}}{{newsletters:iggmg.jpg?0x250}}
-  * Rob, Naveen Michaud-Agrawal, Paul, and Andrés talked about how to talk about Folk (if you have another way of describing Folk to people, let us know over email or in our Discord):
+  * Rob, Naveen, Paul, and Andrés talked about how to talk about Folk (if you have another way of describing Folk to people, let us know over email or in our Discord):
     * {{newsletters:screenshot-2025-03-31-at-5.42.51 pm_discord_convo_1.png?500px}}
     * {{newsletters:screenshot-2025-03-31-at-5.43.03 pm.png?500px}}
@@ Line 231: / Line 247: @@
   * Omar: finish render-to-texture and make folk2 pull request
   * Maybe start working on dual-camera and self-calibration/refinement tech?
+    * Omar: I'm bothered by the baseline-mediocre state of calibration and think we need some new approaches to keep the system calibrated over time -- maybe self-calibration by periodically projecting a tag somewhere on the table; maybe a lightweight form of calibration that just adjusts extrinsics and is easy; maybe an iterative calibration that continuously adjusts (as opposed to the 10-pose batch status quo) so you can really tune the fringes of the projector-camera volume
   * Andrés: finish video playback
   * Andrés: get dot detector demo working in 3D coordiantes
@@ Line 248: / Line 265: @@
   * https://poetical.day
   * https://boofcv.org/index.php?title=Performance:QrCode
+  * https://www.gofundme.com/f/rescue-and-restore-the-aesthedes-1
 ==== Andrés ====
   * [[https://wattenberger.com/thoughts/boo-chatbots|"Why Chatbots Are Not the Future"]] — A really thoughtful piece about how limiting chatbot interfaces are
   * [[https://wattenberger.com/thoughts/our-interfaces-have-lost-their-senses|"Our interfaces have lost their senses"]] — A sequel-of-sorts to the above piece that feel like a very Folk-endorsed idea: computers used to be big and tangible, and as they've gotten smaller, and more convenient, we've also lost all the texture and ability that comes with large, room-scale physical interfaces.