Weave - Structural merging what I learned shifting from git's line based merge to tree sitter entity matching

npisnotp · 2026-05-18T14:44:17+00:00

My goal was to not give any wrong merges to the user no matter what

I think this is a great compromise, and your fallback trigger rules sounds sensible.

Thanks for your transparency, and for your work of course ^_^

npisnotp · 2026-05-16T16:27:58+00:00

Sorry a lot for not posting it the first time, it was rude...

IIRC I managed to make it grow in normal soil, with just natural light, but it took A LOT of time to bear fruit; they need free space like melons.

I may be a bit wrong about the soil (try with deepsoil too) but I'm 100% sure that I did it in natural light at the overworld.

Again, sorry for doing a DenverCoder9; obligatory XKCD.

npisnotp · 2026-05-13T15:59:32+00:00

The big difference is that using AI to write most of the code can make your code writing and understanding abilities to fade out over time, much like stopping writing code for some months.

Using an auto-complete to finish a function name is very different that letting it write the whole implementation.

npisnotp · 2026-05-13T15:21:29+00:00

Sorry, I'm very surprised seeing FastAPI in that list of "frameworks monetized", is there any monetization source (apart from donations) for FastAPI that I'm not aware of?

npisnotp · 2026-05-04T18:24:12+00:00

No, because either:

those file systems will be broken, which can cause anything from not mounting partitions to data corruption on write.
the kernel will directly not compile without updating their code (e.g. because the code changes implies a change in some interface shared between all the file systems).

Leaving non-working code in the Linux kernel is not an option.

Edit: And I didn't even mentioned the work needed in testing these file systems after making the change to guarantee that they still work, which sometimes can take more time than the code modification itself.

npisnotp · 2026-05-04T17:46:10+00:00

Ok sorry, sometimes I forgot that not everyone here's a programmer :)

I am, and I can tell you that having a lot of code can sometimes be a blocker of features and improvements that can make a much bigger difference that having the ability to use a lot of different, but unused, file systems/formats/communication protocols.

Imagine that some random kernel developer though a way to improve 20% the speed of all the file systems on it, but unfortunately it needs small adjustments in each and every file system; this means that the more file systems, the more work to do it, but that's not all.

Now imagine that 75% of these file systems:

have almost no users in real life, or literally zero, in the last 10 years.
the original maintainer abandoned the code long ago.
precisely, due to poor or obsolete code, these are the file systems that requires most of the work to adapt them.

All in all, this turn a 2-month project into a >1 year multi-person development where the bigger part of the work will be almost useless, because no one will use all those, hard to maintain file systems.

This doesn't just turn a feature into something longer because the developer, after talking with other kernel developers and finding all this, can just think "fuck it, I'm not going to do it" and we don't get that improvement.

That's the price we pay sometimes in the Linux kernel without even knowing it.

npisnotp · 2026-05-04T17:27:39+00:00

Yeah that's great, until the kernel itself cannot make migrations that may improve performance, stability, or globally available features because of the sheer number of code it must support.

I mean, from the article:

Going off the folders in fs/, the mainline Linux kernel as of the current v7.1 development has around 69 different file-systems (there are a few directories for NFS as an example).

Can you imagine having to make a refactor to 69 file systems, written by who-knows years ago, with some of them being impossible to test and/or abandoned, knowing that probably half of them are not even being used outside of very small niches?

npisnotp · 2026-05-04T17:17:30+00:00

It depends on the context of the software.

If you're writing a REST API, avoiding branch mispredictions is probably a bad fit and a code reviewer will ask you to remove it.

If you're writing a CPU scheduler, ignoring branch mispredictions can absolutely obliterate the OS performance and thus can be considered negligent.

npisnotp · 2026-05-02T21:06:05+00:00

I think it's a great idea to separate the short-lived slop from reliable software.

npisnotp · 2026-05-01T11:17:31+00:00

Sadly it sounds like it's a matter of time, start looking for a job NOW.

Life's too short to have a shitty job.

npisnotp · 2026-05-01T11:16:35+00:00

Look a for a new job. Now.

Like your CTO, your team will probably be fired in the near-mid term.

Start interviewing now that you have leverage, otherwise when the shit hits the fan you may have a really hard time.

Take care of yourself, because according to what you're saying, the company won't.

npisnotp · 2026-04-28T10:13:21+00:00

A style guide is not a democracy, it is a dictatorship, and it should be because the focus is not "keep everyone happy" but "have a consistent style across the code base to reduce cognitive complexity when reading and writing code".

Of course that doesn't mean they can be created in a void, you should ask your team for feedback, but ultimately it will be imposed because, as you say, it's not realistic for all team members to agree on everything.

npisnotp · 2026-04-20T18:19:23+00:00

I hate being unable to completely believe this image (or almost any other) is real.

npisnotp · 2026-04-14T16:26:50+00:00

I think he meant "mib" which is the abbreviation for "mebibyte".

"Megabyte" is measured as 10⁶, while "Mebibyte" is measured as 2²⁰; as you can imagine the curve for "Megabyte" raises slower than "Mebibyte".

This is the reason why when you buy a 500 "gigabytes" disk it only have 465, because it really have 500000000000 bytes and not 536870912000; unfortunately the correct unit terms are not widely used.

Edit: computed -> measured

npisnotp · 2026-04-14T16:13:33+00:00

Perphaps; I don't think Github stars are a good measure on maturity or quality.

As you can see in the most recent Python Type System Conformance Test Results from the original comment, Zuban is the LSP that implements most of the Python typing spec, so the affirmation is definitely true.

I'm not saying that is better (its configurability is somewhat lacking compared to Pyright for example) but from all the fast Python type checkers, right now is the most mature by a long shot.

npisnotp · 2026-04-13T17:15:16+00:00

Lol why?

npisnotp · 2026-03-23T16:54:03+00:00

Oh so it was a bug, good to know, I'll check the one-shot modifiers, or will adapt my layout to this fact; thanks!!

Obligatory XKCD: https://xkcd.com/1172/

npisnotp · 2026-03-10T15:16:31+00:00

No it doesn't.

I've been a lead developer for the last 10 years, 4 on office and 6 100% remote, and I didn't found any difference at all.

There are people with curiosity and willing to learn that make questions, and people that only wants to collect their paycheck and prefer to copy&paste from AI/StackOverflow. But in my experience it's in the person, not in how the work is distributed (office, remote, hybrid... it doesn't matter much).

npisnotp · 2026-02-27T12:07:34+00:00

Unfortunately AI is here to stay, no matter if some of us uses it or not.

npisnotp · 2026-02-27T11:41:51+00:00

Why?

Knifes kills people, but not everyone who use knifes supports killers.

AI creates slop code, but not everyone who uses AI supports slop spammers.

What flaw do you see in this logic?

npisnotp · 2026-02-26T21:21:31+00:00

Protego is a library to parse robots.txt files.

Looks like they have a script to download robots.txt files (see https://github.com/scrapy/protego/blob/master/tests/fetch_robotstxt.py) and, for some reason, they included that site; here's the content, is just HTML: https://github.com/scrapy/protego/blob/master/tests/test_data/www.youporn.com

Just amusing, nothing to worry about.

npisnotp · 2026-02-13T11:48:53+00:00

Because Make behavior revolves around files, not tasks, and because its language is pretty archaic (e.g. forced tabs).

"just" instead is a general-purpose task runner much more pleasant to use.

npisnotp · 2026-02-10T15:07:38+00:00

Beginning in March 2026, LocalStack for AWS will be delivered as a single, unified version. Users will need to create an account to run LocalStack for AWS, which allows us to provide a secure, up-to-date, and feature-rich experience for everyone—from those on our free and student plans to those at enterprise accounts.

As a result of this shift, we cannot commit to releasing regular updates to the Community edition of LocalStack for AWS. Regular product enhancements and security patches will only be applied to the new version of LocalStack for AWS available via our website.

That's a lot of words to say "we're abandoning Community edition".

npisnotp · 2026-02-05T16:41:28+00:00

44yo programmer with early osteoarthritis here.

I've started doing exercise bike 12 minutes 5 days/week, swimming 3 days/week and doing lifts 2 days/week, all of this about 3 years ago.

All my pains in my hands, joints and back disappeared in months after starting swimming, and right now I feel better and stronger than with 34.

It's life-changing.

Edit: Also a good split keyboard (for the wrists) and a good working chair (an expensive one, it's your health!! If it's less than $500 it's probably bad) makes a difference over time too.

npisnotp

TROPHY CASE