Intralexical

Immediate mode UIs are mostly for debug menus, not even gameplay/graphics. It doesn't need to be accessible to anyone except for the developer(s) choosing the library and making the game. (If the developer has different needs, obviously they can choose another library, unlike users who must live with the developer's choice.) The fourth sentence in the linked ImGUI repository explains this intention very clearly.

You can spend all this energy imagining malice and thinking less of others, but doing so does not add merit to your critique. Nor does it advance the cause of software accessibility.

This post is about a minimal immediate mode library made by a game dev, most suitable for debug menus.

It's unreasonable to treat it as a platform for soapboxing about "the vast majority libs" that are unrelated.

I think it's reasonable to just patch it yourself if it doesn't work with your other tools (Zig). Though thank you for sharing the heads up.

[0] https://github.com/schnaader/precomp-cpp

Why is it surprising that some people who expect results without spending any effort also feel entitled to receiving gratitude without putting in any thought?

I think the "right" way to do it without forking Blender would be to write an OSL shader. Though the way I personally would have done it would be to convert the splat into an angle-dependent Math Node tree for an Emission shader, probably automatically with a Python script.

Trouble is light fields don't block geometry, so they would effectively blend additively and you would see right through them like a hologram. Easy enough to fix though, with a dummy mesh to composite out the background. Or you could just render the splat separately outside Blender, and composite your scene on top of it.

I'm not sure why you would want to, though. The splats couldn't be lit by any of the lights in your scene, nor can they receive shadows cast by any objects in your scene, because they're precomputed light fields. Objects in your scene could be lit by the splats, but it's not immediately clear to me that it would be much more useful or better than just having photos on billboard planes.

I think there might be a misunderstanding that splats provide a way to compute realistic lighting. In reality, they're only a way to store and sample pre-computed or measured lighting AFAIK, hence the need for OP's big camera rig. So integrating them into scene lighting or skeletal animation doesn't really apply.

A profiler like this can be used to identify which parts to rewrite in a faster language. Sometimes it's easier to write everything in Python first, then measure, than guess at the start which parts need to be fast.

You can also get gains by switching algorithms, both in pure Python and when using a compiled library like `numpy`. And there are also some operations, like string manipulation or the `sqlite3` module, where the Python runtime's implementation has already been optimized in a compiled language.

https://www.youtube.com/watch?v=YI3tsmFsrOg&t=5m18s

https://blog.archive.org/tag/decentralized-web/

https://github.com/internetarchive/dweb-transports

Third-party attempt:

https://wiki.archiveteam.org/index.php/INTERNETARCHIVE.BAK

Turns out it's hard! Or maybe just too niche. But you can also help them today, by seeding some of collections that are available as torrents.

The lupus anecdote on its own is irrelevant to the whether the statistics are being interpreted in valid ways or not. Also, I said nothing about luck.

> In one case in the Harvard study, a patient presented with a blood clot to the lungs and worsening symptoms.

That's a single anecdotal fluke from the study, which is misleadingly used to represent the headlining percentages.

If you read the linked paper, it says the LLMs did not outperform any group of doctors in the most important cases:

> The median proportion of cannot-miss diagnoses included for o1-preview was 0.92 [interquartile range (IQR) 0.62 to 1.0], although this was not significantly higher than GPT-4, attending physicians, or residents.

And again, the bigger issue is that skimming nurse's notes and predicting the next tokens, as the study made the doctors do, is not how doctors diagnose medical conditions.

If 90% of patients have a cold, and 10% have metastatic aneuristic super-boneitis, then you can get 90% accuracy by saying every patient has a cold. I would expect a probabilistic token-prediction machine to be good at that. But hopefully, you can see why a human doctor might accept scoring a lower accuracy percentage, if it means they follow up with more tests that catch the 10% boneitis.

They can't just be "configured" by changing a URL. I guess maybe you could self-host the search page for some of the distros, and reuse the parser, but are people really doing that? Otherwise, you'd have to write new code to parse the results, at which point you might as well soft-fork the script anyway.

> Generally I advice against hard doing stuff that changes often and may need to be adjusted for different users or organizations.

YAGNI. And if your org does need it for some reason, you're probably better off running something specifically tailored for your own needs instead of whatever implementation makes it in.

The whole script's only 1300 lines. Would adding spending 150 lines on configuration and littering the user's dotfiles be worth it? Now what happens if the configuration's missing/corrupted? When you update the script, do you keep the old dotfile that might be using a deprecated API, or do you replace the old configuration and clobber any customization the user's done? Oops, there go another 1,000 lines, on edge cases, option flags, conf merging, warning messages... And good luck getting bug reporters to explain their configuration changes!

Also, this stuff doesn't "change often". The distros literally can't change it often, because doing so might break LTS stability. I know it's fun to point out perceived flaws in other people's work, but in this case, the URLs are tightly bound to the parsing logic, which is the right place to put them IMO.

Where else would you put the repository domains?

Even with Cold War money, Lockheed's famed Kelly Johnson couldn't make the logistics work for the CL-400.

> https://github.com/zed-industries/zed/issues/7054

> https://github.com/zed-industries/zed/issues/12589

> TL;DR: Mix of language tooling, unsigned proprietary blobs, corrupted and/or GLIBC-dependent files, redundant copies of already-installed executables. The Node packages especially are able to run scripts on install. Personal preference aside, might also create issues with security laws, certifications. All without user consent.

> Issues opened in January and June 2024. They've been rejected, closed, and opened a couple times since then. No changes directly improving this yet as of April 2026.

So... If you want broad language support via LSP servers, then you're going to have to bring in other ecosystems, and Node/Typescript is a big one that doesn't always have alternatives. [0] That's not a Zed-specific problem.

IMO the real issue with Zed is the "runs them by default without asking" part. Plus the questionable practices with binary blobs and the cavalier attitude in the discussions, when I can just use an editor that... Doesn't do any of that.

[0] https://microsoft.github.io/language-server-protocol/impleme...

Especially for something like a code editor, where plenty of less-shady competitors are available.

https://github.com/zed-industries/zed/issues/12589

TL;DR: Mix of language tooling, unsigned proprietary blobs, corrupted and/or GLIBC-dependent files, redundant copies of already-installed executables. The Node packages especially are able to run scripts on install. Personal preference aside, might also create issues with security laws, certifications. All without user consent.

Issues opened in January and June 2024. They've been rejected, closed, and opened a couple times since then. No changes directly improving this yet as of April 2026.

Personally, I think even if they eventually fix this, given the attitude shown towards their users' machines, I should probably just use an editor where I don't have to worry about it.

Or rather, that maybe we're learning the wrong lesson each time. Maybe instead of "asbestos is bad" or "DDT is bad", the real lesson should have been "biological and ecological systems are incredibly fragile outside of the exact combination of environmental conditions and chemical inputs they've specifically evolved to handle".

Too much complexity, too many delicate mechanisms and feedback loops. Can't afford to keep playing whack-a-mole, every generation we replace the old poisons and add some new ones. If we keep introducing new molecules and quantities of substances that evolution hasn't had a chance to adapt to, then we shouldn't be surprised that we keep breaking things.

But let's not pretend we don't use pesticides for a reason. People gotta eat, and pyrethrins are already an improvement AFAIU, less toxic to mammals, similar to molecules that exist in nature. But still, a cudgel. Maybe we need to take ecological engineering seriously, control pest species by simultaneously cultivating stable ecosystems of insectivores/predators and hyperparasites, poison spray not required...

...Which is a good metaphor for the "experiment" as a whole.

Milgram decided to repeat his gross ethical violation 30 times(!), with dozens of test subjects each time. Overall, the majority of people actually disobeyed the orders to continue with higher voltages.

I think the only reason it's become so popular is because it makes for a shocking story, with grandiose implications. The specific "agentic state theory" Milgram invented is not backed up by his data, and personally, I find it philosophically dubious and psychologically concerning that he gravitated to it.

See:

https://www.bps.org.uk/psychologist/why-almost-everything-yo...

https://journals.sagepub.com/doi/abs/10.1177/095935431560539...

How we see is frozen by not only physics, but also biology. We can't actually see in 3D, only in the 2D of our retinae (and the embedded 2D of light-exposed surfaces). That's true for both 3D and 4D objects. I suppose fish, with their electroreceptive abilities, might be the only animals that can sorta "see" in true, volumetric 3D.

As an aside, thinking of a new color is relatively easy. You can sorta actually see new colors just by making a really good pigment[0], or shooting cone cells with lasers[1].

But there's also the possibility of having a new photoreceptor. In which case, you don't just gain 1 new color. You gain 3 new secondary colors, plus an entire new type of 4 "tertiary colors", each of which is as visually distinct as cyan, magenta, and yellow are. And the colorspace itself becomes a 4-dimensional volume, with every existing color able to blend into smooth graduations of the new cone cell signal.

[0] https://www.youtube.com/watch?v=_NzVmtbPOrM [1] https://en.wikipedia.org/wiki/Olo_(color)

Can we visualize 3D objects? Or do we reason about 3D objects, but only visualize a 2D projection of 2D boundary surfaces embedded in 3D space? I'm definitely not thinking about the inside of my desk lamp, or even its back side, even though those are as much a part of the 3D object as the front surface.

Can you visualize a 1D projection of a 2D object? Probably, but is it a little tricky? How about a 1D projection of a 3D object? And when that 3D object moves? How about a 2D projection of a 3D object, but seen from the inside out with a Hammer retroazimuthal projection, instead of viewed from a distance with the embodied camera eye and wonderfully simple rectilinear(ish) projections that we're so familiar with?

Arguably, I think we can visualize 4D objects. They just look the same as 3D objects, because the visualization is itself a 2D projection. If they move, they look like wobbly 3D objects, as we pick up a different "slice" or "surface".

Now, we don't know very many 4D shapes, because we don't encounter them in our lives. But I think that's fully explained by familiarity, without invoking the idea of an arbitrary limitation. We've all seen lines, sheets, boxes, balls, pyramids— Try describing to a random stranger what a Strandbeest or a Klein bottle looks like.`