That's exactly my understanding as well. This is, essentially, the LLM hallucinating user messages nested inside its outputs. FWIWI I've seen Gemini do this frequently (especially on long agent loops).

I don't know if it's niche, but I like making granola for my friends and family. I give them a big jar and tell them free refills are included ("just bring me the empty jar"). I get pretty good nuts and tend to make largish batches (around 2 kg), and, because of the refills, I get a good sense of who appreciates it — always happy to make more for them. My recipe is here: https://alejo.ch/365

You need help translating a two-step recipe?

On HN?

Are you sure?

I got into designing my own knitting patterns. I enjoy that I can customize everything — the yarn material, color (including marling, helix knitting, double knitting), yarn weight, needle size (e.g., resulting in "airy" vs "packed" textures), knit textures (e.g., stockinette, linen, miss, etc.), construction process (e.g., can I figure out a way to knit in the round vs flat?), cables, gradual increases/decreases, selvedge/cord, desired ease, etc..

I wrote software to generate patterns given configurations and keep track of which row I'm on. https://news.ycombinator.com/item?id=40307089

I am sharing some of my patterns here: https://alejo.ch/2s0

I'm currently working on my second ruana.

Wonderful. Knitting and weaving gets me nerd sniped. Not the act of actually doing them by hand but the geometric puzzle solving part.

These topics hit the HN first page quite often.

A few years ago I helped the wife write her own Haskell software to help her generate her knitting patterns in LaTeX. Fun times.

Should be much easier these days with all the AI help available.

Please consider writing a blog about this. Would love to know more.

I was also baffled. "No formal specification"? Two minutes of browsing is enough to find it: https://github.com/sqlite/sqlite/blob/master/src%2Fparse.y

I'm very well aware of parse.y, if you look into the syntaqlite code, you'd find it's a critical part of how the whole "source extraction" mentioned in the article works [1]

To be clear when I say "formal specification", I'm not just talking about the formal grammar rules but also how those interpreted in practice. Something closer to the ECMAScript specification (https://ecma-international.org/publications-and-standards/st...).

[1] https://github.com/LalitMaganti/syntaqlite/blob/93638c68f9a0...

Looks pretty cool. I think it's great that you support light/dark mode. FWIWI, I'm also a huge fan of Excalidraw.

I wanted to ask you: is there's a reason you use a separate svg file for each (light/dark) mode?

A single SVG file using CSS can change it's own colors based on the user's preference. I have an example here: http://alejo.ch/3jj - the 3 plots should honor your mode (I put the generator code here: https://github.com/alefore/mini_svg)

Just figure I'd ask. If you have a good reason for using separate files, I'd love to hear it (because it probably would also apply to what I'm doing). :)

My goal is that it renders on GitHub as well as on my blog. GitHub doesn’t support css based dark mode afaik

Ah, you have a button for the toggle! Did you know that you can conform to the user's light/dark preference with CSS? Like this:

    :root { --varname: #FFE; }
    
    @media (prefers-color-scheme: dark) {
        :root { --varname: #022; }
    }

Edit: To expand on this, I dislike light/dark toggles. If I have dark mode on, seeing a bright screen and having to search for a toggle is jarring. Just show me the colours according to my preference!

How can you detect the system preferences in the browser?

I answered that in the comment you're replying to. If you want a more authoritative answer: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

Last I checked on this the workaround is embedding CSS inside an SVG, here's a demo: https://github.com/sindresorhus/css-in-readme-like-wat

I used this on a personal project to add a README logo that is dark mode friendly: https://paul.af/github-readme-dark-mode

Waiting for a few days of design review is a pain that is easy to avoid: all we need is to be ready to spend a few months building a potentially useless system.

How long have you been tracking? Can you share an insight you've had from your data?

I've been weight lighting for ten years and initially tried to track things (down to how many reps I did of which exercise, with how much weight) and quickly came to the conclusion that is want worth it for me.

I initially came to the same conclusion. Though I lifted in accord with decent training principles regarding reps and sets, I didn't track for years. As I entered middle age, I started keeping a training log (just one big org file in emacs), mostly out of curiousity. As I entered my 50s, I experienced what Haruki Murakami references in "What I Talk About When I Talk About Running" --- Fat is easy to gain and hard to lose. Muscle is hard to gain and easy to lose. Now I track a couple of critical metrics and it's working great. I weigh first thing every day, track all kcals (even if I overeat), plan and track workouts. I write my own plans pulled from principles in these books (don't work for the company, just a satisfied customer) https://muscleandstrengthpyramids.com/ I don't use the vast majority of the info in those books as I'm just a hobbyist who wants to be healthy and strong. The biggest shift came from learning I was doing waaay too much training volume at the gym while trying to lose fat too quickly; a fine recipe for injury. Now, when I'm in a fat loss phase, I try to lose it as slowly as possible while still making progress. Strength training and fat loss is a very long very slow marathon, not a sprint. Perhaps paradoxically, the awareness that's come from tracking has helped me relax. No need to major in the minors; pretty good is pretty good. The tools I use are a scale, loseit, and org-mode.

The goal in bodybuilding during a gaining phase is to be in a very slight calories surplus (200-300 calories above maintenance, at most) to maximize the amount of time you're building muscle before you need to cut again (bring calories back to a deficit to shed body fat).

Tracking scale weight is difficult because shifts in water weight and hydration can swing the scale 5+ pounds in either direction without any change in body fat. So I pair scale weight with a 7-point skin caliper measurements taken on a weekly basis, along with waist circumference, in order to infer whether body fat is trending up or down. And also take weekly progress photos of 6 angles/poses with consistent lighting, which I share with a coach.

And then you pair that with weighing and logging everything you eat, and you can make small adjustments to your meal plan on a monthly basis to try to stay in that 200-300 calorie per day surplus for as long as possible. (Although most bodybuilding coaches adjust diet based purely on how your physique is changing in weekly check-in photos without the need for measurements, but I like extra data)

> down to how many reps I did of which exercise, with how much weight)

I also do this. Track every exercise, every weight, number of reps. It's necessary for knowing whether you're progressively overloading over long periods of time. Progressive overload becomes harder to measure once you're past newbie gains because you can't increase weight every week, so some weeks the goal is just to squeeze out an extra couple of reps. Which adds up over time

This is obviously excessive for 99% of people. But I enjoy doing it as a hobby. I would absolutely not recommend this level of tracking for health reasons (not necessary) - I find enjoyment in the process.

I track the reps weights of every exercise (in my own app). But the historical values are only useful up to last couple of weeks just to now if the general trends go up and what is stalled. Unless your goals are the numbers themselves and not health, I don’t think there is a reason to track everything. But it is fun.

Thank you for your comment. I like Vonnegut (my favorite is Hocus Pocus) but hadn't read Bluebeard. I only started it and I'm already enjoying it significantly.

Even as an experienced developer who even owned CPAN modules and was very familiar with the Unix ways, Python was a no-brainer.

I mention this on light of the article's claim that this has to do with "a new generation of programmers brought up on … I don’t know, Microsoft systems, Visual Basic and Java". No. The new languages that appeared were just so much much better.

When you have advantages that often come down to "it works great on a teletype over 150 baud" (read, compressed syntax, regex, etc) you will eventually be beaten by something that is easier to read at a glance.

Non-programmers read python and sometimes even Java and say "huh, this is something that could be figured out" - reading perl was reading line noise.

APL is probably one of the most powerful languages out there, but the characters in the syntax scare most away.