Differences

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

--- newsletters:2025-11 [2025/12/08 18:15] – osnr
+++ newsletters:2025-11 [2025/12/08 20:37] (current) – [JPEG frames and Term struct] osnr
@@ Line 28: / Line 28: @@
 From the user point of view, the biggest change is that you now need a blank to edit as your starting point to write a new program. But you can also quickly edit existing programs, which makes the system feel a lot more flexible and powerful. (you're not stuck with whatever programs you printed out, and you can 'ask questions' about anything on the table by opening it in the editor)
+=== Fixed title blinking ===
+Using titles to show the "Edited" notice meant we noticed that titles blinking was a real problem.
+{{newsletters:img_6613.mp4?300px}}
+Debugged it for a while. Found that the display drawlist was empty when blinking out:
+{{newsletters:screenshot-2025-11-20-at-1.03.52-pm.png?550px}}
+Then found that the display drawlist was empty because we weren't able to acquire the collection statement:
+{{newsletters:screenshot-2025-11-20-at-1.09.18-pm.png?550px}}
+[[https://github.com/FolkComputer/folk/commit/13128c99838ad4d0364d71c004ed51df010f26a3|Fixed by retrying acquisition of that collection statement until it works]], since it should always eventually be present.
 ==== Other improvements on folk2 ====
@@ Line 245: / Line 260: @@
 {{.:pasted:20251207-220711.mp4}}
-==== Major memory leak fix ====
+We probably need to think about this a bit more and see if we should expose a richer API so you can choose these timeouts at the caller.
-Omar: For a couple months, folk2 has had another major memory leak (a few MB per second). I spent a while tracking it down. It was a leak of clauses/terms, specifically.
+==== Other folk2 debugging ====
+=== Major memory leak fix ===
+Omar: For a couple months, folk2 has had another major memory leak (a few MB per second). It turned out to be a leak of clauses/terms, specifically, not Jim Tcl data structures or other Folk structures.
+I spent a while tracking it down and [[https://github.com/FolkComputer/folk/commit/ac285cb80e03f467363120f79c6487449cc99b25|managed to fix it]]: it's because we weren't freeing speculatively allocated clauses when their parents no longer existed on statement creation.
+=== "Added tag" pileup (not fixed yet) ===
+I've been hunting down this pileup bug for months but not made much progress on it.
+{{newsletters:screenshot-2025-11-19-at-4.41.04-pm.png?0x200px}} {{newsletters:screenshot-2025-11-19-at-6.40.38-pm.png?0x200px}} {{newsletters:screenshot-2025-11-20-at-2.31.12-pm.png?0x200px}}
+It comes from this claim that tag has a program getting recreated:
+{{newsletters:screenshot-2025-11-20-at-3.06.51-pm.png?500px}}
+I thought I'd tracked it down, but they were just speculative recreations that didn't actually commit to the db.
+=== AtomicallyVersion leak (not fixed yet) ===
+I haven't been able to reliably replicate this. You end up spending huge amounts of time per sysmon tick on garbage collection, because so many AtomicallyVersions are around.
+{{newsletters:screenshot-2025-11-26-at-1.18.13-am.png?500px}}
+{{newsletters:screenshot-2025-11-26-at-1.37.17-am.png?600px}}
 ==== Setup branch ====
@@ Line 293: / Line 331: @@
 === JPEG frames and Term struct ===
-I was thinking about how to speed up the /camera-frame view when we're streaming it in setup and calibrate, and I realized that we're decompressing every webcam frame (for AprilTag detect) (since webcams send you frames as a JPEG stream), then recompressing every frame as a JPEG to send to the web client. Why not put the original JPEG from the webcam in a statement, before we decompress, and just send that to the web client?
+I was thinking about how to speed up the /camera-frame view when we're streaming it in setup and calibrate, and I realized that we're decompressing every webcam frame (for AprilTag detect) (since webcams send you frames as a JPEG stream), then recompressing every frame as a JPEG, writing to disk, then reading back from disk to send to the web client. Why not put the original JPEG from the webcam in a statement, before we decompress, and just send that buffer to the web client?
 That sent me on a journey to try to embed the raw JPEG data in terms/statement clauses/the trie, which led me to [[https://github.com/FolkComputer/folk/compare/90d0a582...3cb882e0|replace the null-terminated C strings with a new length-prefixed Term struct]]. Now you can (in theory) have null characters in terms, so you can put binary data in terms directly. That's a change that Mason wanted to try a few months ago, since it seems both safer and potentially faster.
@@ Line 302: / Line 340: @@
 I didn't end up using this for JPEG transmission -- instead making an Image-like struct that points at the JPEG data on the heap -- because I was paranoid about term copying in and out of interpreters, and the indirect struct lets us only copy when we actually want to read the JPEG data (on output to web client and on decompress).
+Here's what /camera-frame looks like after this change (no more recompress, no more write to disk):
+{{.:pasted:20251208-203638.png?600px}}
 Anyway, more on using the JPEG data next month -- it gives us color preview and faster livestream, which is great, and I'm hoping to use the color in more places soon. I [[https://github.com/FolkComputer/folk/commit/4f901e20cc56f198622f8825deaab8e6b9ebc5b0|switched to the TurboJPEG API]], which I think might let us [[https://graphicdesign.stackexchange.com/a/56130|crop the JPEG without decompressing it first]], which would be great for cropped cameras and stereo camera.