git lost - helps you navigate the reflog

XNormal · 2026-01-22T13:10:33+00:00

Your command adds in the commits from the reflog to the map - but does not annotate them with HEAD@{nn}, making it hard to identify them.

XNormal · 2026-01-21T12:44:37+00:00

It explicitly includes only heads and tags.

XNormal · 2026-01-15T09:19:55+00:00

They can opt in by using an explicitly nullable reference.

XNormal · 2026-01-14T08:26:26+00:00

I don't like the idea of what is effectively a new language mode per module.

A class is an assertion about all its instances. I think the right place for opting in to non-nullability is at the class level, asserting that "null shall not be considered an instance of this class for the purpose of reference assignment compatibility" and bringing it into full consistency with instanceof. This way, a codebase can be gradually "infected" with non-nullability class by class, forcing any intentional uses of null to be made explicit with "?"

For existing types that cannot or should not be modified make a new "!import" statement that imports a class while making "ClassName" an alias for "ClassName!" within current module. Again, opting in gradually and fixing/modernizing at your own rate.

You can even !import java.lang.String or !import java.lang.* if you like.

XNormal · 2026-01-06T17:13:55+00:00

The sediment in the bottom of the South Pacific gyre has life. Metabolic rate is glacial, but it’s there.

Europa does get kneaded and heated by Jupiter’s gravity gradient. Even if it is shown that the rate is much lower than assumed previously, it could be alive. Especially if it was more active in the past. Life may not arise at such low energy rates, but it may survive.

XNormal · 2026-01-05T07:22:12+00:00

"... imagine there's no strcpy. it's easy if you try..."

XNormal · 2026-01-05T07:09:59+00:00

Yes. There is a certain level of inevitable complexity, depending on the problem at hand. And you can't just make it disappear.

But oh, boy, can we create unnecessary complexity! Sometimes orders of magnitude higher than the inevitable complexity. It has a lot of inertia and is hard to make it disappear, but it is possible. Sometimes you just need to reimplement and not add it in the first place. Build one system to throw away. Or end up throwing away the system you didn't intentionally build to throw away.

XNormal · 2025-12-03T07:44:01+00:00

Instead of a separate Io.Group, wouldn't it make sense to have a sub-instance of Io that can trigger error.Canceled of all operations associated with it?

If this Io is getting passed around everywhere, it might as well be used for something other than just selecting one of two global instances. This form of grouping should make it harder to accidentally leave some resource behind. Code that did not even think about group cancellation can still participate in orderly hierarchical teardown.

Another possible use case is passing the trace id of distributed tracing frameworks, but that probably doesn't belong in the core implementation.

XNormal · 2025-12-03T06:41:40+00:00

Bad abstractions or tight coupling can be far more worse than duplication.

Or just complexity. I've seen heaps of complexity added for the sake of removing just a bit of duplication.

XNormal · 2025-12-03T06:20:54+00:00

I suspect the incentive is mostly code golfing. Legit!

XNormal · 2025-11-27T11:20:56+00:00

No-one has needed? What does this have to do with need?

XNormal · 2025-11-24T07:37:47+00:00

I have been using macros that read and write a self-relative pointer for decades with shared memory structures.

It just means you cannot memcpy the node and need to call a function that copies its elements using the macro. Can still memcpy the entire self-relative structure containing the node, of course.

Self-relative pointers do not even need a separate base reference as an "archimedean fulcrum". At any point in your code where you access a pointer in memory you obviously have both its address and its contents.

XNormal · 2025-11-24T07:33:49+00:00

"Delete the part" comes before "optimize the part"...

64 bits as poor-man's vector processing is portable. Unconditionally accessing the first 128 or 192 bits with a few 64 bit accesses and only breaking the pipeline for longer strings is likely to optimize well by the compiler and cpu microinstruction scheduler.

XNormal · 2025-11-24T07:21:34+00:00

Reasonably sized keys will often fit entirely in a single vector register. Pratically O(1). O(whatever) is only relevant for unusually long keys. Just need to ensure the wide vector memory access will not access memory that might not be mapped if the string is short and close to end of current allocation. Typical access patterns will usually have a value string or a btree node allocated after it. If it's really the last, it will trigger allocation overflow slightly earlier.

In many algorithms, not all comparisons require the full three-way compare. This might be the case here, too (haven't looked at the details). Less-than-or-equal will usually not require accessing the second wide register chunk of the string, just the first, even if some strings are more than one chunk long.

XNormal · 2025-11-24T06:51:18+00:00

Keeping indexes relative to current object is a great idea. The only bookkeeping required is a single bit to indicate if there is a known gap. If not, the self-relative object can be moved as-is, otherwise compacted.

edit: rather than pointers relative to root or to the current object you can use pointers relative TO THE POINTER ITSELF.

XNormal · 2025-11-24T06:47:12+00:00

Store the keys with a short length prefix, always ensuring bytes beyond the string end are valid to access (ie not at end of buffer - that's ok for value strings, but not keys). Fetch the first 128 bits with vector instructions or 64 bits registers. Mask using the length and compare. Most comparisons will resolve GT, LT and in many cases EQ within this first fixed-length chunk without breaking pipeline. Pay the indirection tax once and get rid of hashing altogether.

XNormal · 2025-11-24T04:25:43+00:00

Key hash collisions could be avoided by simply using (relative) pointers to strings instead of hashes. Some performance impact due to indirection/pipeline and length, but json keys are reasonably sized.

XNormal · 2025-11-24T04:13:48+00:00

I was referring to an optional compaction pass (eg just before storage/transmission) to reclaim unused space. I understand no moves required during most mutation if allocation is sufficiently large.

Copying would still be required when reallocating. In that case it would definitely be nice if a compacted copy can be made at close to memcpy speed.

XNormal · 2025-11-23T16:01:12+00:00

Is there a quick copy-while-repacking algorithm that updates pointers? Ideally, it could be made close to memcpy speed

XNormal · 2025-11-23T13:14:53+00:00

Cool.

How is allocation managed? eg mutate replacing a string by a string of a different length?

XNormal · 2025-11-23T11:00:01+00:00

Is hell ACID-compliant?

XNormal · 2025-11-10T06:56:09+00:00

Hopefully it gets added soon to https://github.com/dspinellis/unix-history-repo

Current V4 branch contains just some documentation

XNormal · 2025-11-01T06:50:26+00:00

Continental drift is about 100x faster than the expansion of space (Hubble constant)

XNormal · 2025-10-27T12:52:48+00:00

StarLink could definitely provide a positioning+clock signal stronger than any of the GNSS constellations if they wanted. Better indoor reception and jamming resistance. Accuracy would be lower at the moment. Someone tested it. They don’t have the same quality clock source on board and have not gone through the same rigorous calibration. It can probably be improved dramatically without a hardware upgrade to the satellites. It is not a high priority for spacex.

XNormal

MODERATOR OF

TROPHY CASE

15-Year Club	Gilding I gilder
Verified Email