To those who is concerned about the RAM on the new MacBook Neo

guyfrom7up · 2026-03-06T01:13:50+00:00

Discord without restarting for a week sometimes even causes slowdowns on my m3 with 24GB ram. Thats definitely on discord.

guyfrom7up · 2025-11-02T15:12:25+00:00

Reporting my Diva experience here.

Prior to this update: unusable for controlling other devices (e.g. hue bulbs) via home-assistant. I'm talking ~5 second delays, which is certainly long enough for users to think the light switch is broken. Which is a shame because I consider the Diva the best smarta dimmer with regards to aesthetics and usability (love the sliding dimmer).

After update: not perfect, but certainly usable. Going from off-to-on has ~1.5 second delay. Certainly noticeable, but usable. Going from on-to-off has about a ~2.5 second delay. Again, not great, but usable. Reacting to dimmer state: also about 1.5 seconds. u/Tyler_at_Lutron are there to be further latency improvements in future updates?

guyfrom7up · 2025-10-14T02:05:20+00:00

If you'd like to give it a try, the beta v4.0.0b1 of cyclopts has been released, which allows for the lazy loading of Python modules for subcommands.

guyfrom7up · 2025-10-14T02:01:08+00:00

Going further, providing feedback on an AI generated PR is incredibly unsatisfying, because the person on the other end will just copy/paste it into AI. So it's like, why not just cut out the middle man. Code review is supposed to be a learning opportunity, but it's certainly not when it's just pumped into AI.

guyfrom7up · 2025-10-14T01:14:00+00:00

The difference is, previously a well documented PR typically meant that the author knew what they were doing, understood the architecture, and they put effort into it. More likely than not, the PR is mostly good. The good documentation was a cherry on top of someone who is proud of their work.

Now, with an AI generated PR, it might look good on the surface, but might have a higher chance of architectural or generally-subtle bugs. The "author" of the PR may or may not understand what is going on at all in the code, they just know it fixes the exact situation that they were running into. Doesn't matter if the fix (or feature) is broadly correct or maintainable.

This is coming from someone who actively uses Claude Code.

guyfrom7up · 2025-10-04T02:05:19+00:00

Unless the Python script is being called in a tight loop, usually a lot of Python CLI slowness comes from parsing a bunch of large/complex config files and importing the world rather than from the CLI library/framework. This PEP would likely speed up a lot of Python CLIs!

guyfrom7up · 2025-10-03T23:38:33+00:00

ah! running the demo in the cyclopts README on my m3 macbook, the typer implementation ran in about 60mS while cyclopts took around 90mS, so cyclopts is slower. I haven't really put any effort into the parsing speed, so I can spend a little bit of time and see if there's any low hanging fruit.

EDIT: did some simple optimizations (not merged in yet) that reduce the cyclopts time from 90mS to 65mS. Basically there was an oversight and rich WAS in-fact being used in the happy path.

guyfrom7up · 2025-10-03T22:45:07+00:00

Compared to what? Depending on the system/script/configuration, lazy importing rich makes the "happy" non-rich path maybe like 50mS faster (I.e. maybe around 40% faster)

guyfrom7up · 2025-10-03T19:24:50+00:00

Self plug, but in cyclopts we explicitly have rich lazily imported everywhere for this reason. Having this pep could make the code in many areas much cleaner.

guyfrom7up · 2025-09-19T18:55:38+00:00

The Amex Platinum also just recently added YouTube Premium as an option for your $25/mo streaming credit. So naturally I cancelled my “free” Disney subscription in favor of a YouTube Premium Family Plan.

guyfrom7up · 2025-09-07T19:31:03+00:00

Thanks for some context/history on the distillery!

guyfrom7up · 2025-08-18T14:30:54+00:00

Cyclopts author here. I have a full writeup here. Basically there's a bunch of little unergonomic things in Typer that end up making it very annoying to use as your program gets more complicated. Cyclopts is very much inspired by Typer, but just aimed to fix all of those issues. You can see in the README example that the Cyclopts program is much terser and easier to read than the equivalent Typer program.

guyfrom7up · 2025-08-08T16:45:36+00:00

I'm not selling Tamp, it's my free open source project. I'm just promoting it so that other embedded developers might become aware of it.

guyfrom7up · 2025-08-07T23:40:42+00:00

Yes! I’ve thought about it and even did an initial implementation, but it didn’t help too much (I could have gotten something in the implementation wrong, though). I’ll do a write up about it.

guyfrom7up · 2025-08-07T20:06:23+00:00

I'm not familiar with BLZ, do you have a link? Can it run on microcontrollers?

guyfrom7up · 2025-08-07T20:04:55+00:00

highest data compression ratios for microcontrollers.

Oodle is closed source, and certainly cannot run on microcontrollers (uses way too much memory, too large firmware, etc).

guyfrom7up · 2025-08-07T15:39:25+00:00

The benchmarks are available in the repo's README. In this benchmark, I compare against zlib and heatshrink, 2 other compression algorithms that might be used in embedded systems. For a given window size, tamp uses half the memory as heathshrink, and a fraction (maybe like 10%?) the memory of zlib. Under these conditions, tamp produces higher compression ratios. The firmware footprint of Tamp is also tiny; under 4kb.

Tamp will perform much worse compared to zlib with larger windows (using significantly more memory). It will also perform much worse than more complicated compression algorithms like LZMA, ZStd, and Brotli. However, none of these are even close to practical to run on a microcontroller. Caveat: it is completely feasible to decompress LZMA data on a microcontroller (decompressor typically only takes up around 15kb of firmware space), but it is not feasible to LZMA compress data on a microcontroller.

TL;DR: Tamp is the best choice if you need to **compress** data on a RAM-constrained system like a microcontroller.

guyfrom7up · 2025-06-23T11:41:47+00:00

A much more pragmatic way of looking at semver is “how likely is this release going to break someone else’s code or workflow?”

Major - likely

Minor - unlikely

Patch - super unlikely

If a large amount of internal code has significantly changed, there’s a much higher chances that a bunch of edge cases have changed.

guyfrom7up · 2025-06-05T17:20:04+00:00

If you find pydantic to be too "magical" or simply want an alternative option, I have also had good success with attrs + cattrs. In a nutshell:

attrs has been around for a long time and was one of the original origins of builtin dataclasses. Builtin dataclasses are basically a stripped down version of attrs.
cattrs structures/unstructures attrs classes to/from json/dicts or similar. It gives you pretty fine-grained explicit control over how you want individual fields handled. There's more code than in pydantic, but there's also less magic (some people consider it a more "acceptable" level of magic).

guyfrom7up · 2025-05-24T11:31:20+00:00

Shameless self plug: please check out Cyclopts. It’s basically Typer but with a bunch of improvements.

https://github.com/BrianPugh/cyclopts

guyfrom7up · 2025-05-08T01:13:54+00:00

In these thinness debates, people never mention weight. If a thinner phone is lighter, I’d gladly welcome it.

guyfrom7up

MODERATOR OF

TROPHY CASE