> Partly because I wanted my config to survive without breakage across Emacs releases. Partly because I was tired of dealing with package repositories, mirrors going down in the middle of the workday, native compilation hiccups, and the inevitable downtime when something changed somewhere upstream and my job suddenly became debugging my very long (at the time) config instead of doing actual work.
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
Yeah, the frontend is from scratch. Each bullet is just a div contenteditable. The DOM is the state (Claude Code suggested the usual frontend pattern of separate state and rerenders, but I rejected that). Apart from the DOM, content is dumped to local storage. Bullet folding and zooming work mostly just by showing and hiding the bullet divs i.e. the whole note tree is all the time in the DOM. It's conceptually quite simple and Claude Code is good at writing code that traverses the DOM. There's of course a lot of operations like indent/dedent, copy-paste, undo/redo etc. but they've been quite painless to add.
Trying out vibe-coding (so mostly not even reading the code) a note-taking web app that's essentially a simplified and dirt-cheap to host Workflowy clone. That seems to me like an easily disruptible SaaS in the sense that note-taking is a very generic app, I only use a small part of the feature set of Workflowy and find the price far too high given that. A lot of other vibe-coding around me I see is throw-away junk, but my intention is to actually use this. The frontend is mostly done and working quite nicely already. Sync is then more crucial to get right to avoid data loss and I think I'll review and rewrite myself more of that.
I recently revised my script to rely on (1) no commits in the last 30 days and (2) branch not found on origin. This is obviously not perfect, but it's good enough for me and just in case, my script prompts to confirm before deleting each branch, although most of the time I just blindly hit yes.
No, it's been working without problems so far. I'm using Anthropic for what it's worth. I ask the LLM to first do some reasoning and then return a JSON array on the final line. Sometimes I've seen some Markdown backticks there, but no irregularities more than that.
Looking at the console messages with the LLM reasoning, it does seem to work quite nicely for deduplication. Your example is probably even a lot easier than news articles, where you can have many articles from different viewpoints about the same event.
I don't actually plan to run this as a service so there's some things hard-coded and the setup is a bit difficult as you need an API key and a proxy. Currently it's just experimentation, although if it works well, I'll probably use it personally.
I've been experimenting with using LLMs for a content recommender system. Specifically I've built a news reader app that fetches news articles from multiple RSS feeds, uses an LLM to first deduplicate and then score them. The user can then rate the articles and those ratings are used as few-shot examples in the LLM scoring prompt. Any resulting low score articles (uninteresting to the user) are hidden by default and visible ones scaled by their score on a dynamic CSS grid like on a traditional newspaper front page. Looking good so far, but still testing and tweaking.
My favorite of the year would be Maxim Gorky's three-part autobiography: I read "Childhood" and "In the World" (a.k.a. "Amid Attendants") and just started the last part "My Universities". Gorky drifted as an orphan from house and job to another and describes an interesting array of characters he came across, mostly poor and misfortunate, but many of them good as well.
"He took me under the arms, lifted me up, kissed me, and placed me firmly on the jetty. I was sorry for him and for myself. I could hardly keep from crying when I saw him returning to the steamer, pushing aside the porters, looking so large, heavy, solitary. So many times since then I have met people like him, kind, lonely, cut off from the lives of other people."
It's unfortunate that Python and R don't really have any out-of-the-box means of opening data files from arguments, but if you do this kind of stuff on a daily basis it's something that you can set up. My not directly usable examples below.
Agreed! It's easy understand "LLM with tools in a loop" at a high-level, but once you actually design the architecture and implement the code in full, you'll have proper understanding of how it all fits and works together.
I did the same exercise. My implementation is at around 300 lines with two tools: web search and web page fetch with a command line chat interface and Python package. And it could have been a lot less lines if I didn't want to write a usable, extensible package interface.
As the agent setup itself is simple, majority of the work to make this useful would in the tools themselves and context management for the tools.
I used to hate matplotlib because of its awful API and awful API documentation. These days I just ask an LLM "add thousand separators on the y-axis", "add a vertical line ar zero" etc. and now I never need to look at the API documentation and it feels somewhat tolerable.
LLMs feel to me a nice fit here because there's just so much users might want to do with the chart styling. Past approaches that I've seen offer some kind of "quick selections" of common stuff and while they can help you get started, they quickly become annoying when you need to add some final tweaks not covered by the tool/API/whatever.
I think the choice of using functions instead of classes + methods doesn't really fit well into Python. Either you need to do a huge amount of imports or use the awful `from siuba import *`. This feels like shoehorning the dplyr syntax into Python when method chaining would be more natural and would still retain the idea.
Also, having (already a while ago) looked at the implementation of the magic `_` object, it seemed like an awful hack that will serve only a part of use cases. Maybe someone can correct me if I'm wrong, but I get the impression you can do e.g. `summarize(x=_.x.mean())` but not `summarize(x=median(_.x))`. I'm guessing you don't get autocompletion in your editor or useful error messages and it can then get painful using this kind of a magic.
I don't quite agree, but if this was true, what would you tell a junior colleague in a code review? You can't use this function/argument/convention/etc you found in the official API documentation because...I don't like it? I think any team-maintained Pandas codebase will unavoidably drift into the inconsistent and bad. If you're always working alone, then it can of course be a bit better.
Building on top of Pandas feels like you're only escaping part of the problems. In addition to the API, the datatypes in Pandas are a mess, with multiple confusing (and none of them good) options for e.g. dates/datetimes. Does redframes do anything there?
Planning to switch to NumPy 2.0 strings soon. Other than that I feel all the basic operations are fine and solid.
Note for anyone else rolling up their sleeves: You can get quite far with pure Python when building on top of NumPy (or maybe Arrow). The only thing I found needing more performance was group-by-aggregate, where Numba seems to work OK, although a bit difficult as a dependency.
1. Does this make the apps show up as separate windows in Alt+Tab and a Dock etc? (FWIW I use GNOME + Dash to dock + Wayland)
2. Let's say you have a mail app and you click a link. Does that link open in the separate default browser?
I remember trying these command line options for Brave/Chrome, but I couldn't find a way where both of the above were working and thus they didn't feel like proper apps. I've only been using this for something like Apple Music, where I never click on any link that takes me outside. For everything else, like mail and notes, I've been using pinned tabs, but that feels suboptimal too.
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
https://github.com/radian-software/straight.el