o11c

The hope for semantic HTML died the day they said "stop using <i>, use <em>", regardless of what the actual purpose of the italics was (it's usually not emphasis).

I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline.

I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.

Any statically-typed language has this. In pseudo-Java:

  class Parent {};
  class Child extends Parent {};
  class Wrapper
  {
      Parent foo;
  }

  w = new Wrapper();
  w.foo = new Child();

  evaluate w.foo;
  // static type: Parent
  // dynamic type: Child

... really?

Many words came to mind when I saw this warning, but nothing really adds to the incredulity of this one word.

Hmm, the is `type` the static type or the dynamic type, for languages where both apply?

The author of the article is claiming it extends beyond ads.

That does not appear to be what the court actually said, however.

And I 100% believe that all advertisements should require review by a documented human before posting, so that someone can be held accountable. In the absence of this it is perfectly acceptable to hold the entire organization liable.

At a glance, that looks like worse than merely the negligence of using a new technology.

The whole point of 3D printing is that the material is moldable when hot but rigid when it cools. And people really should be aware that engines get hot.

Related: doctors will refuse to test you to see if what you're suffering from is a particular condition unless that condition actually has a known treatment.

Those are not unrelated. Both from my family and from looking at the research, there's a strong correlation between long/difficult births (sometimes explicitly hypoxia) and autism.

There's a reason I prefer "lots" over "infinity".

For your "quicksort of 4 elements" example, I would note that the algorithm doesn't care - it still works - and the choice of when to switch to insertion sort is a mere matter of tuning thresholds.

For the "all zeros" case, my concern is that you said you're forcing a reset every 1024 words. This implies that if you have N kilowords of zero data, then it takes N times as much space as a single kiloword of data.

Good compression algorithms effectively use the same storage for highly-redundant data (not limited to all zeros or even all the same single word, though all zeros can sometimes be a bit smaller), whether it's 1 kiloword or 1 gigaword (there might be a couple bytes difference since they need to specify a longer variable-size integer).

And this does not require giving up on random-access if you care about that - you can just separately include an "extent table" (works for large regular repeats - you will have to detect this anyway for other compression strategies, which normally give up on random-access), or (for small repeats only) use strides, or ...

For reference, BTRFS uses 128KiB chunks for its compression to support mmap and seeking. Of course, the caller should make sure to keep decompressed chunks in cache.

This is missing a lot of context.

What integer patterns does it do well on, and what patterns does it do poorly on?

How many strategies does it support? It only mentions delta which is not compression. Huffman, RLE, variable-length encoding ...

Does it really just "give up" at C/1024 compression if your input is a gigabyte of zeros?

Better option: just wrap it in a unique struct.

There are perhaps only 3 numbers: 0, 1, and lots. A fair argument might be made that 2 also exists, but for anything higher, you need to think about your abstraction.

Compiler speed matters. I will confess to not as much practical knowledge of -O3, but -O2 is usually reasonable fast to compile.

For cases where -O2 is too slow to compile, dropping a single nasty TU down to -O1 is often beneficial. -O0 is usually not useful - while faster for tiny TUs, -O1 is still pretty fast for them, and for anything larger, the increased binary size bloat of -O0 is likely to kill your link time compared to -O1's slimness.

Also debuggability matters. GCC's `-O2` is quite debuggable once you learn how to work past the possibility of hitting an <optimized out> (going up a frame or dereferencing a casted register is often all you need); this is unlike Clang, which every time I check still gives up entirely.

The real argument is -O1 vs -O2 (since -O1 is a major improvement over -O0 and -O3 is a negligible improvement over -O2) ... I suppose originally I defaulted to -O2 because that's what's generally used by distributions, which compile rarely but run the code often. This differs from development ... but does mean you're staying on the best-tested path (hitting an ICE is pretty common as it is); also, defaulting to -O2 means you know when one of your TUs hits the nasty slowness.

While mostly obsolete now, I have also heard of cases where 32-bit x86 inline asm has difficulty fulfilling constraints under register pressure at low optimization levels.

I would expect a little benefit from devirt (but maybe in-TU optimizations are getting that already?), but if a program is pessimized enough, LTO's improvements won't be measurable.

And programs full of pointer-chasing are quite pessimized; highly-OO code is a common example, which includes almost all GUIs, even in C++.

For laptops specifically, opening them up and blowing all the dust out can be a huge difference. After that, if the fan is making noise, it's not worth attempting recovery. If attempting this, consider whether your source is cheap enough in the case your test exposes this.

Blowing the dust out does run into the problem of some laptops being designed to only open with use of a chainsaw. I've ruined a couple laptops that way.

The amount of money the US Government pays just for that 40% should be enough to cover all 100%. We know this is possible because it happens in other countries, which have shorter waits and more coverage since that talking point keeps being brought up despite collapsing in the face of reality.

I have no real knowledge of React from the developer side, but as an ordinary user who occasionally pokes around in dev tools to assign blame, React clearly is failing at Simplicity.

There are so many React websites where I see weird update bugs (e.g. updates for some parts of the page delayed by 3 seconds [not blocking render, the rest of the page is updating], or total wipe of something instead of incremental upgrades - weren't these the very problems React was supposed to solve?).

Mere excessive bloatedness I don't blame React for; all sorts of web dev fails at that.

===

The main question I have for Remix is: does the explicit `.update` trigger immediately, or does it wait so it can coalesce multiple updates?

Hm, what about using `%` itself?

Since this is really confusing without any context, "1964" is a Nintendo 64 emulator for Windows.

Healthcare costs [...] The only difference is with an employer intermediary, [...]

That's missing the biggest problem, which is that the employer gets a free chance to extort the employee in all sorts of illegal ways lest they be cut off and die.

Wage theft is perhaps the biggest-value type of crime every year (sources disagree, but it's certainly higher than many), and that's only one kind of illegal thing employers do when they have all the leverage.

It would take someone who actually knows React writing an answer that explains how it is different. Usually newbies are not in a position to understand when version differences are relevant and when they aren't.

On SO, it's often best if questions are somewhat version agnostic, and different answers address different questions.

It's claiming "questions on SO are deleted because people don't understand them", as opposed to the reality that moderation is done by the more experienced users (in this case the least-experienced close voter had 5K reputation).

The deleted question (linked twice, once mislabeled as "mailing list" for some reason) is of the form "Where in my IDE is the option to do X?". While questions about IDEs are not entirely off-topic on SO, they face an uphill battle, and this particular question didn't even have any code.

The question might have become a good fit for SO if the asker had bothered to follow the "edit this question to add ..." instructions ... or if anybody who follows the tag had done it either. Note that deletion only happens after a question is closed for 30 days with a negative score and no answers, and is essential to keep search meaningful.

It uses a sandwich; see https://fil-c.org/runtime

Clippy really ... wasn't bad? It mostly stayed out of your way, occasionally showed a button to perform a useful task, and could interact with the help system without having to click through 3 menus.

It wasn't a panacea but it was at least positive-value, unlike most current AI.

I was reading the `fontconfig` source recently (to help me understand what, exactly, is the difference between the various `fc-*` tools and their options) and some of the code scared me.

I thought, "for sure this is a use-after-free" ... but it happened to be safe because some function performed an undocumented incref, and the return value of that function was kept alive.

So this is definitely a high priority thing to port!

... I suppose the interesting question is: if some of my dependencies are ported, and some are not, is there any way a normal compiler can call into a Fil-C-compiled library for just a few functions?

Let's suppose arithmetic is a solved problem and only consider manufacturing and distribution.

The major barrier to self-managed dosing, even if you want to do it properly, is that there's a huge difference between one pill and two pills. And trying to cut pills in half (if even possible for a particular pill structure) often makes very uneven halves (which is a problem for day-to-day variation even if a consistent "10% more than half" dose would be fine).

I have seen dose differences of ~10% to be ignored between brands or over time, so that's probably safe-ish to ignore (certainly much better than the current 50%-if-lucky-else-100%). But counting out 10 pills is certainly a pain; realistically, aiming for a 5-pill typical dose would be more reasonable.

My impression from looking at OTC costs is that the bottle costs more than anything, so manufacturing probably isn't the bottleneck. A side-effect of the current "one pill" mindset, in conjunction with expiration dates, is that low-dose pills are generally not available in higher counts, but there's nothing fundamental about this.

Are there any "delayed/gradual release" concerns that get worse for many small pills rather than one large one? If so, is it really more significant than the wrong-dose problem?

I'm not familiar with Zod, but one thing that is quite important on the user end is to produce multiple (but, per policy, not infinite) error messages before giving up. That is, list all environment variables that need to be set, not just whichever one the code happens to be first.

This could be implemented with `??`, something like: `process.env.NODE_ENV ?? deferred_error(/temporary fallback/'', 'NODE_ENV not set')`, but is probably best done via a dedicated wrapper.

That's okay since X11 is stable and not very crash prone for the last few decades.

The WM and Shell are far more likely to crash, which is it's completely fucking retarded to move any of their logic into the display server.

Crashes of the now-merged display server / window manager / whatever. Why does everybody keep talking about "applications" like they're the problem people have with Wayland? Our problem is the Wayland server itself.

Both window manager and shell were historically extremely likely to crash, whereas the display server was very resilient (and the session script would restart the WM and shell as needed). I'm not sure how separate the shell is nowadays, but more than just the traditional duties of a WM have been embugged into the display server.