RossBencina

I think you are correct. Clearly I am still traumatised by the cost of converting floats to ints in the x86 era.

I am probably dating myself here, but in C the default rounding mode is round-to-nearest and the cost of switching the x86 FPU to truncate (and back) in order to perform the truncation is extremely expensive. Perhaps other instruction sets have truncate-to-integer instructions that ignore the active rounding mode.

Agreed. I was opining on the psychological "getting used to" aspect, not the technical merits.

x and y are integers represented as floating point

  > d = trunc(x/y);     // floor works for unsigned
  >
  > // NOTE: if only want 'd' and it's being converted to an
  > // integer then the truncate or floor operation is
  > // free in the float to integer conversion.

Please show me how to portably truncate or floor a floating point value to an int in C for "free".

> The third I suppose I care less about, just because I've kind of become used to it

I've never become used to it. My impression is that the constant churn has accelerated. Plausible drivers are (1) normalize novelty as desirable (like fast fashion), (2) product developer/designer incentive structures that reward revolutionary change over progressive refinement. The global switch to subscription models and continuous deployment didn't help.

> more like services and less like physical tools that never change.

I'm not sure that constant change is a characteristic feature of services, especially not professional services.

It used to be that you bought a piece of software and used that version until you decided it was worth upgrading, like a particular physical tool. The software still evolved, just like the design of physical tools can, in principle, evolve.

All that said, agentic AI tooling is evolving so rapidly I'm not sure an expectation of stability is realistic.

Indeed. I guess this is why [[gnu::musttail]] and [[clang::musttail]] exist.

https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Statement-Attr...

Interesting article about a worthy topic, even though I disagree with some it. Side note: I expected to see mention of design by contract and function preconditions/invariants/postconditions.

I don't think the article is well founded. Before you can discuss usage you need to establish the semantics for assert(). The author touches on this in the introduction but then leaves the details unexamined. In particular I'd need to know: can assertions be disabled (as with C/C++ NDEBUG)? does the project have a policy of leaving asserts in production builds? or are asserts only ever enabled for development and testing. if used in production, do you care about the overhead of checking assertions in performance critical code? if an assertion is hit does it always log and panic/terminate? or does it throw a catchable exception? What is the runtime context of the code: is it a server process with a supervision tree? is the failure paradigm "let it crash"? is it an interactive program where the only supervisor is the user? is it a use-case where a program crash is undesirable and/or safety critical? is it a library with unknown use-cases? Are the developers in full control of the program inputs and outputs that trigger asserts?

As a general principle for layered systems, when there is a policy decision to be made, lower-level code should delegate upwards to higher levels, which should implement the policy. Throwing an exception or returning an error code is frequently better than terminating (if you squint, crashing out to the supervision tree is more like throwing an exception than it is like terminating.)

> Correctness - All possible function input and output values which do not have full value coverage should have assertions covering them.

Only if you control all of the callers. Library users would prefer an invalid parameters error/exception.

> Safety - When performing operations that can have unwanted, known, or unknown side effects, assertions should be used to prevent those conditions from happening.

Why assertions? If it is safety critical, shouldn't these checks be mandatory?

> Development - Use an assertion to enforce assumptions on values and state. These assertions can optionally be compiled out of code when coupled with proper testing.

This is where preconditions/postconditions/invariants come in. If safety is important you probably want to leave them in place. A runtime contract violation should enter a fail-safe state.

> Documentation - When writing code, use assertions as self documenting guardrails around your logic. Use assertions to enforce values and state which might be unclear from documentation or hard to decipher from reading code.

I do this, but in this case you either need to be 100% sure that the exception won't get hit, 100% sure that the exception won't make it into production builds, or okay with production crashes.

  > var error = system_call(...);
  > assert(!error);

Writing this is equivalent to providing an arbitrary third-party with the ability to crash your application with a user-unfriendly error message. Your program should have code paths to handle all error conditions. One of them can be { print("unexpected result from system call. exiting.") exit(); }

Is it patchable? Are there any known-working fixes that can be broadly applied?

One thing that wasn't tried is that the ASCII path could build a block-wise bitmap of non-ASCII blocks. Then the unicode pass need only process the contiguous ranges within the bitmap. This would be simpler to implement when combined with inigyou's no-reallocate suggestion.

If you can kill-off the extra buffer allocation code path that's got to be a win.

+1 great idea. I get the impression that some of my sibling comments thought that you meant fold all code points in the opposite direction, but it it's clear you mean change the fold direction for only those two code points.

We've had mechanical/automated/algorithmic transformation of copyrighted works for over 100 years now. There are plenty of non-AI systems for translating code from one language to another. In the context of shifting a program between programming languages LLMs are just another algorithmic transformation technology. In any case, shifting a program from one language to another is not some kind of magic copyright erasure technique, whether or not an LLM is used. The law has codified procedures to assess infringement. If mechanical means is used (i.e. an LLM) the output is literally a function of the input. Good luck.

It has to be the right information, filtered and presented in such a way that supports the task. Any kind of human in the loop UI has to manage user cognitive loading. Task saturation is real.

Agree. Security fixes are the killer app for automatic updates. I would argue there are other kinds of fixes that should make the cut: crash bugs, data loss bugs. Maybe even broken features, interaction annoyances, etc. Then it becomes a slippery slope, and the risk/benefit trade-offs are harder to arbitrate.

I don't think "ill-conceived" is giving enough credit. It has been clear to me for a long time that "security" is the justification for pushing the user to update, but the updates themselves are frequently leveraged as a vector for other, less user-friendly, practices.

Very cool, thanks. But this requires the iPhone/computer to have an internet connection. I'm thinking about alternatives to GPS for non-network continuous time synchronisation.

Agreed. Your self-managed vendoring example is quite near one end of the continuum. I'm suggesting that there might be space for better tooling from there all the way to the NPM end. For example, automated and/or collaborative triage and review of change sets so that you don't see the changes you don't care about, but can easily review and integrate critical fixes.

IANAL and I don't think you are either. Be careful making simplistic inferences about a complicated system. Human "translation" is one thing, algorithmic "translation" has seen separate treatment in IP case law.[1] Whether this has relevance to LLM transformation or recall I don't know.

[1] https://en.wikipedia.org/wiki/Adobe_Systems,_Inc._v._Souther....

I'm curious: how large is it really? As I understand it, Kakehashi is targeting command line programs, especially Xcode-tools. How much non-POSIX/Mach/BSD interface do Mac command line programs use? How much of that is not already open source. How much of that changes yearly? The only thing that comes to mind is process security for codesign and notarization but I'm just guessing.

> to be in control of the dependencies

Maybe I'm out of touch, but I think control over dependencies is underrated. It's not just about freezing and pinning. There should be better tooling to support the whole dependency evolution pipeline. For example updates should be reviewed/ingested/integrated/validated based on local policy not based on source release schedule.

"For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance."

For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead:

https://www.youtube.com/watch?v=rHIkrotSwcc

Agreed. But you make it sound like the worst case is necessarily fatal. It depends on the use-case. The workable cmpxchg algorithms will make progress on at least one core each round. In a push or pop operation one of the cmpxchg must have succeeded for another to fail. The atomic xchg algorithms that I know of have other undesirable pathologies (e.g. a suspended producer can stall the consumer).

In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?

> Rather than all that to turn an e-reader into a tablet

All what? Most Boox products are Android tablets with e-ink screens and pen support. Few are marketed as, or realistically interpreted as e-readers.

Australia here, no radio time as far as I know. Lately I've been wondering whether accurate time could be derived from terrestrial digital TV signals.

> Why has it taken this long to catch on?

Intel didn't put SIMD in their chips speculatively; there was a lucrative market. HPC presumably. Maybe SIGINT.

There have always been SIMD accelerated libraries, but I assume that you're talking about more widespread hand-coded SIMD application code (either in assembly or using compiler intrinsics.) For audio DSP this caught on when SSE2 launched around 2000-2002[0]. All things being equal, the user being able to run twice as many of your plugin as your competitor's is a real commercial advantage (being super-slow compared to your competitors is also not a great look.)

Not all applications have such forces at play. For most of the intervening period computers were getting faster every generation anyway, so users were seeing performance improvements when they upgraded their hardware, with no developer effort. For me, adding features delivered more value to users than making the existing product run faster.

A few things that factored into my personal limited use of SIMD over that time frame (even though I did write some inline asm): overhead of maintaining compatibility with multiple CPU generations. i.e. AMD and Intel were not in lockstep (still aren't, see AVX512); my users' hardware was all over the shop ranging from latest and greatest to older than you would imagine; I wanted good OS backward compatibility; autovectorisation was supposed to be just around the corner (honestly it's not bad if you limit the compiler to a recent instruction set). All of this could have been addressed, but features were a higher priority.

In addition, that period was the era of "write once run everywhere." Portable code was desirable. Having inline asm was seen as dirty, using instructions that only ran on specific makes and models of CPU more so. SIMD was alien to the mainstream developer zeitgeist.

In recent years the calculus has changed: CPU clock speeds are stagnant, most if not all application processors have SIMD units. More people understand that most CPU compute is in the SIMD units. We seem to have reached a critical mass of open SIMD algorithm development in less niche domains (e.g. simdjson). But SIMD code is still not write-once-run-everywhere.

[0] https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

Here's the video: https://www.youtube.com/watch?v=DQNqo2xtq6U

> be more implicit

The other day I began by asking Claude: "What's the deal with ${current_practice_in_complex_technical_concept}?" and was talked down to like I was an idiot. Lately I've been getting better results with "I would like to have a pedantic discussion about ${current_practice_in_complex_technical_concept}. Please define the main terms of art, then I will ask my questions."

Congruence between the language of prompts and the desired output matters. Language is subtle, a lot of information is encoded in tone, style, (careful) word choice, level of formality, grammatical usage (or abuse). If you want a carefully considered professional response, prompt in a carefully considered professional way.

Every field has its shibboleths. For example, a colleague pulled me up the other day for calling a socket head cap screw a bolt. Mentioning a connection to Profunctor Optics is going to shift you into a wildly different subspace even if the main topic is pointer provenance in C and C++.

Indeed. I primarily used PIMPL when I want to avoid polluting public header files with implementation detail #includes in cases where forward declarations are impossible or unwieldy and inline methods are irrelevant.

Thanks for sharing. Hadn't seen that particular presentation of binary splits before.

> You have to be confident by default or you'll never get anything done.

Crippling doubt can happen. Blind confidence has its own hazards. You only need to be confident that you can proceed, in spite of having provisional, incomplete knowledge. "But if you grip to your beliefs too tightly, you will not recognise The Truth when it comes knocking on your door." (forget who said that)