setr

Roguelikes are the ultimate in procgen technology, and should be the basis of any design. (DF is the ultimate simulation but uses procgen as a tool to achieve it; a different vein than NMS trying to explore the procgen and its direct outcomes itself)

1. Any imaginary world needs to be internally consistent to be interesting. Procgen does not void this rule; randomization needs to be gated to that internal consistency.

2. A world can be composed of multiple environments, and each environment can a different definition of internal consistency. Dungeon Crawl Stone Soup does this very openly and to fairly good effect, but pretty much any decent procgen game will inevitably end up with the same choice, because it's what enables you to play with various procgen systems/rules while still having a coherent overall game.

3. Generalizing 2, procgen systems generally do not start from nothing; You embed reasonably well-defined bases (races, weapon forms, etc) and then apply randomization on top of those bases to form the final element. Meaningful fundamental variation in those bases leads to guaranteed meaningful variation in the end result.

4. Games are fundamentally interactive systems. Generating a thousand variations without actually changing interaction is equivalent to generating exactly one variation. A blue orc vs a red orc is a not real variant, unless you make it so by attaching effects / statuses / capabilities. The color distinction is then a signal into the more abstracted changes that have occurred. This is where NMS falls over -- the images have changed, but the interaction has not.

5. A corollary to point 4, changing numbers without changing interaction is equivalent to doing nothing. If a meaningful damage threshold is functionally every 10 points of damage, then generating numbers 0-9, 11-19, etc is equivalent to generating just the numbers 0 and 10. This is where borderlands falls over -- a million variations in guns, but the vast majority of those variations are just numeric differences that don't change anything in practice.

6. If the procgen applies to equipment/builds, you pretty much need permadeath as a driver for exploring a procgen game and its systems, because you need players to explore for a local optima. Exploring the space for a global optima in a procgen game inevitably devolves into a gambling simulator, because players optimize out the fun, and the optimal play is to the kill unit XYZ repeatedly for the 0.5% drop. Games like Terraria fall into this trap (though Terraria resolves it mostly by making unit XYZ be trivially summon-able bosses)

7. Procgen can never guarantee interesting results; You inevitably need a system of vaults/artifacts -- hardcoded quality items -- to guarantee periodic interesting locations/items. Ideally more notable than average generation, but less than strictly optimal so as to not overpower the other systems -- an issue I've had with games like Diablo 3, where finding an item-set was vastly more powerful than anything else that I acquired for the next 5+ hours, eliminating the entire looting system (and even character skill system, since it forced my build too)

8. Decent Procgen is inevitably rule-based, with possibly multiple chained-rules each doing their own rolls, to ensure coherency. Ideally the rule-chain is roughly discoverable from the end results (by virtue of following internally consistent and apparent rules) -- an end-result that cannot be explained is indistinguishable from pure-random, and pure-random in incoherent. See any Tabletop RPG generation tables.

9. Hell, just start any procgen design from tabletop RPG tables.

10. The number of variations that can be produced is meaningless. This is only for marketing.

11. A procedural system that generates exactly once is fairly pointless. Permadeath.

12. A procedural system is inherently unfair, because you cannot guarantee difficulty, proper placement, unit composition, etc without removing the procedural systems outright. Embrace the unfairness, and design around it. Permadeath.

13. A procedural system is inherently unfair; you need to give some guaranteed items with guaranteed results to navigate an uncertain world (e.g. escape tools).

14. It's always good to enable some control by the player over the procedural generation. Choice of environments, chances at additional loot, etc. You want the player to engage with procgen rules, because they're interesting (and if they're not, what are you doing?), and the easiest way is to give them tools to manipulate it to their advantage. Also permadeath.

I’m not sure you have to squint; an mview is just a cached query. The only difference between an mview and a cache is the “incremental” part of the equation.

That is, my only disagreement is the lack of gusto

TFA links to PixelPie as a GPU implementation https://www.cs.umd.edu/gvil/projects/pixelpie.shtml

Also Casey, but his much cooler/deterministic solution to grass placement, to avoid lines

https://caseymuratori.com/blog_0011

Ignoring aesthetics, there’s simply significantly more detail produced by max

I feel like the baseline teaching is trivially necessary, and should simply be assumed in these kinds of assessments. Getting someone to invest themselves emotionally into a subject is both infinitely harder and valuable, and should always be the focal point.

That is, the true “origin” isn’t worth much — the origin of interest is whatever kicked off the feedback loop of joy —> learning —> joy (in my own case, it was learning djikstra’s algorithm)

Per the article, the replicas are configured the same. MIXED is just dynamically selecting the format automatically, and it seems to be the case that AUTOINCREMENT has fundamentally broken semantics under replication.

And instead of erroring out when replicating, it instead chooses ROW format and plays a game of complete nonsense.

The user error is in not sufficiently reading the docs, but it seems to me MySQL is going out of its way to wrap the noose

It’s hard to imagine someone creating these for PRs? Unless it was auto-generated, but even then it’d only be relevant for fairly large/novel PRs — and then it’s functionally the same as documentation use case.

You’d also probably need some mechanism to visually diff the flowcharts to participate in discussions/changes

The thing I’ve never understood is why SQL itself is not the target of attack. There’s already an inherent language abstraction with the planner; Postgres in theory could be the JVM with any number of languages implemented on top. Including a language that lends itself to composition and auto generation of PL functions.

ORMs are fundamentally difficult because of the mapping problem, but SQL code builders should be trivial. Auto-generating and exposing every DB functionality as a type-safe $LANG function should be trivial. Instead, they’re also accidentally difficult because building SQL is difficult.

Outside of SQL, you’ve got datalog… and that’s about it. And I guess whatever horrors the NoSQL crowd keeps coming up with

PL/SQL is cursed and the unstandardized library system means every DB’s ecosystem is anemic.

Instead of smashing strings, you can code with all the affordances of C90 and still get the chance to smash strings together if you need to do anything beyond utilizing simple variables (EXECUTE) — now with an even worse string manipulation stdlib. And you also get the privilege of working with the some of the most worthless parser errors known to modern man. As an added bonus, DB IDEs are universally worse at text-editing & refactoring than the equivalent application editor

You can reuse code through extensions/external instead, and have access to real programming languages with actual libraries… but now you’re kicked out of managed environments because it’s not whitelisted, and even if you do run it, you’re back to smashing strings together like a Neanderthal trying to communicate to your DB.

Sprocs/functions are useful because they do useful engine things — they run locally with the data, they have an easier time playing with transaction flow, some logic is much easier to express with a cursor instead of set logic and you get to avoid most of the penalties you’d have otherwise.

They do absolutely nothing to make SQL a less terrible interface to your database, except by stuffing it under a rug (CALL).

Learning SQL doesn’t absolve you from the fact that, from the perspective of your PL, you’re smashing arbitrary strings together like a Neanderthal, and you can be offered all the support otherwise given to your string smashing problems (exactly none)

It also doesn’t absolve the fact that SQL is not a particularly well-designed language for smashing strings together like a Neanderthal. In fact, you might even say it’s absolutely horrid at it, with random keywords, extraneous syntax, and general lack of compositional capabilities.

The relational model is fantastic — Codd is Godd, after all. The engines are a work of art. The SQL language is a shitshow. PL/SQL and all its variants are a crime upon the PL community. The programmatic interface to a database is a shitshow, because it is SQL and only SQL. The SQL standard is a joke and standardizes nothing.

None of this is contentious, or should be, once you’ve learned SQL.

That’s just how all Diablo clones work; basically consider it asset reuse…

Power fantasy during leveling / campaigning always comes from being “ahead of the curve” gear/build wise — the subject of your combat is rarely meaningful

> It's true they don't HATE people, but it's also true they absolutely have no conscience in negotiations and have zero concern about relationships.

Sure. Like a lawnmower.

For that purpose, you’re perfectly well off just leaving it as an opaque blob; compress, base64 encode and stuff it into a string/varbinary column and call it a day.

You don’t even need to store it in pg itself; stuff it into a cheaper datastore like s3 and just have the locations stored in pg.

The only thing to optimize for is cost & storage. Access/retrieval doesn’t matter for a once in 6 months process.

Also what is this revolting formatting strategy you’ve found?

Idk how big of a market pure city driving would be; I imagine most city traffic sources from the suburbs

Unless this is meant for like taxis, similar to auto-rickshaws in Southeast Asia. Or maybe short distance car rentals like zipcar?

For these agentic AI systems, like a human operator, the LLM needs to have a wide variety of operations available to it, gated by permissions and authentication. They should be calling APIs. They should be making DB queries with RLS. The reasoning model is to identify which APIs to use when and in which order… not to execute arbitrary code in prod. The same expected of a human screwing around with prod.

Leaking private repos is occurring not because an LLM is involved, but because the LLM isn’t being required to forward the authentication requirement from the user, and engaging the APIs with that limited permission sets. And it would be just as useful having had that limitation in place

The LLM is currently running around like a level 1 tech support holding admin creds, and you’re just hoping they doesn’t do anything stupid with them by giving them a bunch instructions on what not to do.

I think prompt injection vs sql injection is actually not far off — both are the direct results of blindly trusting user input for no particular reason and entirely unnecessarily, with a system that has far more power than it needs to do the task it was meant to do. It also has the same incorrect “solution” given out — sanitize your inputs — instead of correcting the problem at the source (why is an agent for repo X able to read repo Y in the first place?)

Prompt injection in the non-agentic scenario — like getting an LLM to answer questions from its training you don’t want it answering — is inevitable and unavoidable. But things like TFA, deleting prod, etc are well within reach

The problem with ORMs are

1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result

2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently

3. They make simple queries simple, and hard queries absolutely revolting

4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking

5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways

6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB

The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset

The smell is 50% the asset packs available in the respective stores. The other 50% is the default character controllers and the default lighting settings

The issue I find with this pattern in docs/tutorials is that the prefix makes it very obvious which functions are from this library.

It's particularly worthwhile when looking at the bigger examples that might involve another library, or stdlib functions/libs I haven't dealt with before

Wait

TFA is like 90% a copy of whatever the PDF is on this website. It just prefixes it with a small story

Both are hosted by nature.com though...

> It takes just as much work to delete a row as it takes to insert a row. Why wouldn't it? Obviously you have to do almost all the same operations: write a log, write the deletion, update indices, replicate it, etc.

It takes far more work to delete/update than insert. My recent example is updating ~2TB of text data was about 40x slower than inserting 12TB (was trying to correct some large text truncation that occurred during migration into PG, ended up being faster to redo).

Apparently AI models have gotten decent at geoguessr... Might be worth a shot?

https://news.ycombinator.com/item?id=43724935

If my understanding is correct, the use of palantir by creatures leads to their own downfall, both for evil and good characters. So following through, it's very useful for it to be in evil hands

honestly I dont want plan hinting so much as being able to ban table-scanning / nested loops / etc on specific tables, and be able to set that independent of actual table-size so I can coerce its failure in dev environments

> literally save like 20 seconds in some cases because 1 HUGE query becomes 8 straightforward ones with maximum index usage.

I don’t understand how splitting a query up would have any relationship to index utilization; the planner should trivially pick up on it?

Also are you sure you’re not solving a different problem[0]? Doing joins manually being faster doesn’t smell right, except in the case of data duplication increasing total resultset size substantially

Like the cost of increased network load from not filtering through the join should outweigh anything else in the equation

https://learn.microsoft.com/en-us/ef/core/querying/single-sp...

> I covered that in my talk, which will be eventually published on YouTube.

Any idea how I get myself notified once it’s up? Or a YT account to poll

> This is because taking up 100% of the CPU effectively captures 100% of RAM

Isn’t that only true though specifically at 100% CPU utilization?

If it were at 90% CPU, then you have no RAM capture, and then you can’t say anything about whether 80 or 800MB should be taken; it’s only a freebie if and only if literally no other program can do work on the machine.

I don’t see how you can map X% CPU utilization to Y% RAM capture.

Like a program could be network heavy, CPU light and mmaps a large file? Or streaming a file from disk with a constant memory allocation, but doing heavy nonstop CPU work.

The CPU / RAM capture ratio would be wildly different; the ideal for your program, while other competing programs of unknown behaviors exist, I don’t see any way for hotspot to approximate

If you take out ordering, then lookups on your SoA are now a search, and n-field lookup on an entity is now a JOIN operation.

The smarter you get about it, the closer you get to an OLAP db

Which leads to my theory… I feel like Bevy could be implemented on top of an in-memory DuckDB and get away with it

It’s a good abstraction layer, and a fundamentally good/effecient model of organization and data management. It’s a horrible language, has a meaningless standards doc, some of the worst debugging tooling of modern system and generally any tooling outside of the RDBMS engine itself is 20 years stale.

The only difficult part in arguing this is that RDBMS != SQL != RelationalAlgebra, and it’s very often forgotten