On YouTube, I stumbled across the channel "Daddy rolled a 1" which does long form (often an hour long and sometimes closing in on two hours long) deep dives into the early D&D "why was it done that way?"
I forget which one it was that reminded me first of it... Fafhrd and the Gray Mouser was brought up recently in "Was Early D&D Really as Dark as We Remember?" pointing out that while the world was grim, people in Lankhmar were often enjoying life and it wasn't and the grimdark of some modern fantasy.
From the intro to the Audible version of The Swords of Lankhmar (and the text version of Return to Lankhmar)
it's not stalled, as that would imply that it waits for something, which is not necessarily the case with bubbles. most often it shows lack of proper pipelining or wrong pipeline dependencies (pipeline A waits for pipeline B, pipeline C waits for pipeline B, while pipeline B waits for an event X, now you've just made all three pipelines stalled on event X - not good).
When an engine stalls, the implication is that the chain reaction that drives it is failing - I don’t think that is the case with a GPU as it will quite happily sit there drawing watts til you give it things. In systems nomenclature the inverse term for bubble is utilisation. This or that link is or node is using x% of its capacity. Indeed, if you monitor your GPU with nvidia-smi you will see that very term in the instrumentation.
Coincidentally, I recently looked at using CUE as a config file format, but it looked like it was too syntactically complex and unwieldy for them to edit compared to, say, TOML (which is warty-but-usable) or YAML (which is incredibly complex and has too many footguns).
Also, in order to work with it and to understand why their configs weren't working beyond simple error messages or worse, a config file that is technically correct but does something they don't want. To do that, if seems like they'd have to (a) understand unification, (b) be able to find and read the spec files, (c) overcome the syntactic similarity between data and schema, (d) be able to build mental models of why the data and schema combine to cause the symptoms they have. I decided to not use it for that purpose (yet).
I _want_ something like CUE, which is why I was looking at it, so...
Does anyone here have any real-world experience using it as a config and/or data format and ingestion engine for users that are _not_ complexity-loving CS-ophiles like myself who love nothing more than a cool new way of munging data?
You make it sound like unification / cue's model has some unnecessary complexity but the reality is that unification is very intuitive and whole model is one of the best (formalized!) ideas at _simplifying_ configs/data generation/transformation/validation.
Their docs are very approachable, consumable in single evening.
I like CUE a lot. We use it pretty heavily for schema enforcement of CRDs. That being said, it is pretty complex and learning to use it was anything but straight forward.
CUE seems like the opposite: a typed data structure used to produce artifacts via a unification algorithm and feeding data to external tools to "render" those artifacts.
The same thing I wonder when one claims Jupyter notebooks to be literate programming.
I think cue might be close but to be honest, some practical examples would have been helpful to get a better impression of the point the article is trying to make.
I used Perforce a lot in the 90s, when it was simple (just p4, p4d, and p4merge!), super fast, and
never crashed or corrupted itself. Way simpler, and easier to train newbies on, than any of the alternatives.
Subdirectories-as-branches (like bare repo + workspace-per-branch practices w/git) is so much easier for average computer users to grok, too.
Very easy to admin too.
No idea what the current "enterprisey" offering is like, though.
For corporate teams, it was a game changer. So much better than any alternative at the time.
We're all so used to git that we've become used to it's terribleness and see every other system as deficient. Training and supporting a bunch of SWE-adjacent users (hw eng, ee, quality, managers, etc) is a really, really good reality check on how horrible the git UX and datamodel is (e.g. obliterating secrets--security, trade, or PII/PHI--that get accidentally checked in is a stop-the-world moment).
For the record, I happily use git, jj, and Gitea all day every day now (and selected them for my current $employer). However, also FTR, I've used SCCS, CVS, SVN, VSS, TFS and MKS SI professionally, each for years at a time.
All of the comments dismissing tools that are significantly better for most use cases other than distributed OSS, but lost the popularity contest, is shortsighted.
Git has a loooong way to go before it's as good in other ways as many of its "competitors". Learning about their benefits is very enlightening.
And, IIRC, p4 now integrates with git, though I've never used it.
I've used CVS, SVN, TFS, Mercurial, and Git in the past, so I have plenty of exposure to different options. I have to deal with Perforce in my current workplace and I have to say that even from this perspective it's honestly pretty bad in terms of how convoluted things are.
I don't disagree at all--p4 was kick-ass back in the day but the world, and our expectations, have moved on. Plus, they went all high-street enterprisey.
What makes it convoluted? Where did it lose the beat?
sqlite-vec is a work-in-progress and not ready for general usage! I plan to launch a "beta" version in the next month or so. Watch this repo for updates, and read this blog post for more info.
Here are a few settings that make GNU make a bit faster, and enable multi-line, strict-mode bash scripts as recipes (make recipes are normally sequences of single-line sh invocations)--and enable quietude & tracing: https://github.com/barries/polling_state_machine_cpp/blob/ma...
reply