whacked_new
Joined 19 years ago
Joined 19 years ago
Then I threw actually useful things at it: find this directory of pdf scans, and create an interface where I can browse the files, preview them, and query an lmstudio server, and auto-rename the pdf based on the content.
Another is to ssh to a remote machine that has a particular file organization structure, and give me a preview gallery.
Nothing is particularly complex, but I couldn't be bothered to making that myself. It's also something that I would've used in emacs (the preview function is like dired-preview-mode in emacs), but a graphical interface would perform better.
But in practicality, at least at this point, bb wins out by sheer expansiveness of ecosystem. I was working on a mishmash of an editor interface that combined obsidian with heptabase, directly in GT. It kind of worked. And the amazing thing is, everything has just a single representation: window positions displayed as text automatically have 2 way bindings across widgets, because they are the same data. But even with agents doing everything, 2 things creep up.
First is in JS/TS, all these binding problems are solved 1000x already. You can fake shared memory with callbacks and the agent won't lose track. In GT you move the cursor around, and have to decide at what point do you convert a widget representation to source representation, and when to restore the widget: is it a delay? is it after changing lines? is it after you move off the text? before or after the whitespace? There's a package for that somewhere in npm that answered all these questions, and it has tables, and it's performant. It doesn't do the 2% stuff that GT does using its magical shared memory representation (which also makes TS->smalltalk porting not straightforward), but you can still tape over it with sheer optimized code.
The second thing is that GT got really slow with all the data structure re-interpreting and rerendering. As "dirty" as bb is in reloading dynamic code, the runtimes are so optimized, I wanted the markdown nodes to be GPU-accelerated in bb, and it turns out they already were.
Ironically after watching glamorous toolkit videos on youtube, I was recommended a talk by Geoffrey Litt about dynamic documents [2] and at the end of his talk I learned about bb [3], which has much better agent integration compared to GT. Like @thelazydogsback said, with agents, the programming language matters less.
* dependent on velocity
Tangentially, in my 20s I was in an audience seating and sat next to an old person. And I smelled a new kind of odor. It was displeasing, but not like body odor. I quickly realized it's an old person smell. It really just makes you think "old person". I assume there's some biological wiring in there.
Does it pain me to say it? Nah, I'm numb :-/
temperature, humidity, audio in AND out!!!
But yes, open source would be better. If physical portability is not a requirement, Xiaomi hygrometer 2 with this custom firmware https://github.com/atc1441/atc_MiThermometer is quite excellent
And maybe Remacs will get reactivated https://github.com/remacs/remacs/wiki/Progress
Maybe even I'll be able to do it when I wait for the bus!
main drawback is that it's not lossless ;-)
but this is great. I hope this actually becomes a format that wraps the weights and transformer module (maybe this can also be NAS-optimized too?). Maybe it would even work for video?
It's like calling gzip but instead of compression level you choose kolmogorov complexity level
en/zh/ja/emacs/vim
mainly python, clojure, typescript
whacked on gh
also whacked on hn but that one's now a placeholder