newsletters:2024-03
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| newsletters:2024-03 [2024/04/02 02:29] – [What we'll be up to in April] osnr | newsletters:2024-03 [2024/04/02 02:48] (current) – Add Forrest youtube links & embeds admin | ||
|---|---|---|---|
| Line 21: | Line 21: | ||
| * {{youtube> | * {{youtube> | ||
| - | * [[https:// | + | * [[https:// |
| + | * {{youtube> | ||
| + | * {{youtube> | ||
| * [[https:// | * [[https:// | ||
| Line 49: | Line 51: | ||
| Nice side benefit of the new evaluator: it boots much faster, making it faster to iterate and test things, because it's only compiling virtual-program-level C code (Gpu, AprilTags); the kernel is statically compiled into a monolithic folk binary. (this feels like a reasonable tradeoff, since no one was messing with the kernel in practice anyway) | Nice side benefit of the new evaluator: it boots much faster, making it faster to iterate and test things, because it's only compiling virtual-program-level C code (Gpu, AprilTags); the kernel is statically compiled into a monolithic folk binary. (this feels like a reasonable tradeoff, since no one was messing with the kernel in practice anyway) | ||
| + | Some remaining stuff to do: | ||
| + | * Performance optimization so we can get it to beat old evaluator, which is the whole point | ||
| + | * Implement Collect & text/labels (the major missing functionality in new evaluator) | ||
| + | * Fix memory leaks (it might end up better than old evaluator here too, since that is leaky anyway) | ||
| + | * Thread management so we can spin up new worker threads as needed to run Whens when current workers are asleep/ | ||
| + | |||
| + | There are still some high-level challenges from parallelizing the workqueue, stuff that we 'got for free' from having a single thread and converging to a fixed point. like, what order do you do operations in, how do you avoid wasted work, what does ' | ||
| ==== Live USB & distribution ==== | ==== Live USB & distribution ==== | ||
| Line 56: | Line 65: | ||
| The main thing is making a live USB that just boots into Folk and walks through calibration & network setup and can install to disk. (the near-term application is to distribute a version of the CNC stuff as a demo that is immediately useful) | The main thing is making a live USB that just boots into Folk and walks through calibration & network setup and can install to disk. (the near-term application is to distribute a version of the CNC stuff as a demo that is immediately useful) | ||
| - | I've been using Debian live-build, which seems to be the de facto standard for making live USBs: documentation/ | + | I've been using Debian live-build, which seems to be the de facto standard for making live USBs: documentation/ |
| (I've been building the live .iso in an Intel Linux UTM/qemu VM on my Mac laptop, which is a little annoying. I think the live build process is already slow, it's not incremental at all, so it's installing all the stuff for this 1.4GB Debian setup from scratch on each build, and it's even slower because it's in emulation. I also burned some time trying to make the live USB itself work in a VM to test on my laptop -- the graphics doesn' | (I've been building the live .iso in an Intel Linux UTM/qemu VM on my Mac laptop, which is a little annoying. I think the live build process is already slow, it's not incremental at all, so it's installing all the stuff for this 1.4GB Debian setup from scratch on each build, and it's even slower because it's in emulation. I also burned some time trying to make the live USB itself work in a VM to test on my laptop -- the graphics doesn' | ||
newsletters/2024-03.1712024983.txt.gz · Last modified: 2024/04/02 02:29 by osnr