otsaloma

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.

https://github.com/radian-software/straight.el

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.

To avoid losing any work, I have a habit of never keeping branches local-only for long. Additionally this relies on https://docs.github.com/en/repositories/configuring-branches...

How do you handle missing values (NA)?

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.

https://github.com/otsaloma/news-rss

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.

Python (uv + dataiter, but easy to modify for pandas or polars): https://github.com/otsaloma/dataiter/blob/master/bin/di-open

R (as per comment, requires also ~/.Rprofile code, nanoparquet in this case): https://github.com/otsaloma/R-tools/blob/master/r-load

https://archive.ph/MLJHu

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.

Something similar for GNOME: https://github.com/ghi59/floating-mini-panel

Been using it for a couple weeks now and find it really nice. Tried some auto-hide panel extensions before, but this is much better.

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?

Agreed, never had a problem with the speed of anything NumPy or Arrow based.

Here's my alternative: https://github.com/otsaloma/dataiter https://dataiter.readthedocs.io/en/latest/_static/comparison...

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.

Two questions:

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.

The current memory use of string arrays is another major issue, glad to see this being worked on!

How is that convenient? Missing data support belongs deep in NumPy itself (or any other similar package) so that operations can do the right thing and missing values propagate correctly. For example, let's say you want by definition missing values to sort last. If you roll out your custom missing value marker, you'll also need to roll out your own custom sort function. And the same for a whole lot more stuff.

np.nan is only for floats, doesn't help with integer, boolean, string etc. Also, datetimes have NaT, but it's troublesome to e.g. do different checks np.isnan() or np.isnat() depending in the data type. And we don't even have np.nat, but need np.datetime64("NaT"), so it's just confusing.

Still no NA?

The data frame is a Python dict and I consider that a feature so that users know how to e.g. loop through columns with .items() etc. That then means that bracket notation is reserved for column names only (i.e. dict keys). So, that's why a separate function is needed.

Data frames for Python (and some other stuff):

https://github.com/otsaloma/dataiter

Comparison against dplyr and Pandas for a quick overview:

https://dataiter.readthedocs.io/en/latest/_static/comparison...

That's specifically the gain here, you don't need to keep learning new build tools or language-specific tools. Make works for all languages, all kinds of projects, has been around since forever and is not going away. It's the only build tool you need to learn.

To me it seems both Pandas and Polars sacrifice API for performance, just using different approaches to achieve that performance and thus differently bad API. There's obviously some amount of tradeoff there and no shame in tilting in scale in one direction, though it would be refreshing to be upfront and honest to users about that.

Additionally, Pandas seems an organically grown API. These days with more experience and more data frame implementations to learn from, it should be possible to do better, something I only partially see when looking at Polars.

As a developer of a couple GTK apps, I look at the deprecations in GTK4 and GTK5 with horror. At least one app I'm going to stop maintaining latest with GTK5.

GIMP still doesn't have stable release out with GTK3. Inkscape took a long time. I bet both will have great trouble in the future. It seems we're moving towards GTK apps being either core GNOME (maintained as paid work by Red Hat) or trivial little apps like on mobile (either simple to port or just short-lived). Everything else will slowly die out.

There's already way too many people in the field who see these Stable Diffusion, GPT etc. in the news and want to do something like that. Stable Diffusion looks impressive, but I have no idea what the business use case for that is. Likewise lots of people want to do "deep learning" but most companies don't have that kind of data or it doesn't make sense otherwise. 99% of data science work is more boring -- what you need is try to understand the business, be familiar with a wide range of different methodology and have an exploratory mindset to look for a good solution to a particular problem. This is not to say you can't do "AI" or "deep learning", but a narrow focus, overcrowded market and no existing skills are not a good combination. There's plenty of business need for general data engineering and data science though that can also serve as a path forward if not interesting to you as an end.

IndexedDB is probably what's meant, Local Storage (if taken literally) is a simpler and perhaps too limited a solution. There are some options that make IndexedDB easier to use, I've been using PouchDB, which works well. If syncing to Dropbox, you'd then dump the database into a JSON string/file and use the Dropbox SDKs to sync that. If syncing to a database, you can do something more efficient.