Might wanna go for something like this to be safe:
"Why I'm quitting my job to migrate from Rust to Common Lisp for my crypto and SQLite based 'self-hosting email sucks' themed nft tweet generating SaaS platform to prepare it for IPO, after $faang_corp cancelled my account."
What's so cool about Folsom? I would argue Mission Street is a lot more interesting. Folsom (especially the southern bit) is beside that massive I80/101 flyover and that area is mostly ghettos and warehouses. I think Airbnb has their HQ there.
Branch coverage just means you’ve taken every branch, not every combination of every branch, for starters.
Then there’s branchless boundary conditions e.g. your software might fuck up on overflow, but there’s no branching, at least not in your code. Just things which get incoherent in ways you had not anticipated.
A simple example is when somewhere in code you set a value that causes you to go into the wrong branch later. You may have tested that every single branch does what it is supposed to, but this "state here causes unexpected behavior there" can still be open.
Frankly, I don't get it. What do you do with this karma? What does it even mean? If we could exchange it for money or whatever, I could understand. It's not even an indicator of competence or anything, just being in line with the majority and spending time on HN. It's the equivalent of points and badges on Google Maps.
Internet points is the most important currency of your heart. It defines your worth as a human being.
Also I think some HN features are gated on karma? I’d like a feature where the markup isn’t complete shit but apparently I don’t have enough karma for that.
I would never touch a .0 release of a new version of SQLite. No shame against them or their fantastic quality--it's just that I have lived through literal decades of watching minor database bugs shatter data value and undermine all efficiency.
When I see a .3 or better, I start thinking a version is usable. The fact the SQLite moves their quality needle this quickly is encouraging.
You really do not need to exercise such caution with SQLite.
Because of the DO-178B status, SQLite is sufficiently reliable to be used with in-flight avionics (on Airbus A350 models, noted so far).
The test suite requires every branch instruction to be exercised at the machine-language level, in both directions if conditional.
The software that we are used to is not held to this exacting standard.
If we were talking about Oracle or SQL Server, .0 version hesitance is valid, and SQLite tests have crashed both of them, repeatedly. Obviously, they cannot be used with applications requiring DO-178B compliance.
And yet TFA shows that 3.39.0 introduced a new feature (right joins), and 3.39.1 fixes a logic bug in exactly that new feature. I suppose you're right that it's not a crash, just an incorrect result.
Add (long overdue) support for RIGHT and FULL OUTER JOIN.
Add new binary comparison operators IS NOT DISTINCT FROM and IS DISTINCT FROM that are equivalent to IS and IS NOT, respective, for compatibility with PostgreSQL and SQL standards.
Add a new return code (value "3") from the sqlite3_vtab_distinct() interface that indicates a query that has both DISTINCT and ORDER BY clauses.
Added the sqlite3_db_name() interface.
The unix os interface resolves all symbolic links in database filenames to create a canonical name for the database before the file is opened.
If the SQLITE_OPEN_NOFOLLOW flag is used with sqlite3_open_v2() or similar, the open will fail if any element of the path is a symbolic link.
Defer materializing views until the materialization is actually needed, thus avoiding unnecessary work if the materialization turns out to never be used.
The HAVING clause of a SELECT statement is now allowed on any aggregate query, even queries that do not have a GROUP BY clause.
Many microoptimizations collectively reduce CPU cycles by about 2.3%.
I wonder if proceeds from this commercialisation alone are sufficient to keep the OSS effort going or whether the devs also have other paid endeavours.
My understanding is that the source is open for anybody to see and do whatever, but closed to contributions.
Also, they have some big names who have paid them a lot of money to keep the project alive for the next few decades. Airbus the plane manufacturer is one example.
There are these two podcast episodes [1] featuring sqlite founder Richard Hipp which I encourage you to listen. He is a thoroughbred.
I'm not sure why a minor SQLite bugfix release needs to be posted here.