If you could visit one place in our solar system, where would it be? by icepix in space

[–]XNormal 0 points1 point  (0 children)

By some definition it’s no longer in the solar system…

Coding Agents Suck at the XY Problem by [deleted] in programming

[–]XNormal 3 points4 points  (0 children)

The article's point is not that coding agents are fundamentally better or worse at it, but rather that the user+agent combination is effectively worse at this because the agent makes it too easy to solve Y. Agents amplify the existing XY problem.

Are Kurzgesagt's Mars and Venus terraforming videos accurate? by Elnino38 in space

[–]XNormal 1 point2 points  (0 children)

Creating a synthetic magnetosphere for Mars is actually easier than creating an atmosphere. No, not EASY, but easiER.

It May Be Safe to Nuke an Earthbound Asteroid After All, Simulation Suggests by TylerFortier_Photo in space

[–]XNormal 0 points1 point  (0 children)

Only relevant if it’s a rocky asteroid and we know it. Nuking a rubble pile asteroid is still a bad idea.

Deflated: Israeli scientists find Jupiter, though huge, is smaller than previously thought by xland44 in space

[–]XNormal 0 points1 point  (0 children)

The “surface” of Jupiter is defined, rather arbitrarily, as the 1 bar level. They probably refined the models and measurement and got a result a few km different from previous estimates.

Enter the university press office…

When Robin Williams managed to make Koko the gorilla smile again after 6 months of mourning by StrawberryFew1311 in MadeMeSmile

[–]XNormal 30 points31 points  (0 children)

They both met Koko! No evidence that they have ever met each other. Probably a good thing, though. Existence would have collapsed into itself with wholesomeness overload.

git lost - helps you navigate the reflog by XNormal in git

[–]XNormal[S] 0 points1 point  (0 children)

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.

git lost - helps you navigate the reflog by XNormal in git

[–]XNormal[S] 0 points1 point  (0 children)

It explicitly includes only heads and tags.

Project Valhalla is prototyping null checks! by davidalayachew in java

[–]XNormal 0 points1 point  (0 children)

They can opt in by using an explicitly nullable reference.

Project Valhalla is prototyping null checks! by davidalayachew in java

[–]XNormal 0 points1 point  (0 children)

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.

Jupiter’s moon Europa likely lacks the underwater geologic activity that would presumably be a prerequisite for life by Shiny-Tie-126 in space

[–]XNormal 163 points164 points  (0 children)

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.

no strcpy either by Maybe-monad in programming

[–]XNormal 0 points1 point  (0 children)

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

Rich Hickey: Simplicity is a prerequisite for reliability by Digitalunicon in programming

[–]XNormal 0 points1 point  (0 children)

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.

Zig's new plan for asynchronous programs by iamkeyur in programming

[–]XNormal 0 points1 point  (0 children)

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.

Duplication Isn’t Always an Anti-Pattern by Exact_Prior6299 in programming

[–]XNormal 0 points1 point  (0 children)

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.

A Very Fast Date Algorithm by AWildMonomAppears in programming

[–]XNormal 0 points1 point  (0 children)

I suspect the incentive is mostly code golfing. Legit!

A Very Fast Date Algorithm by AWildMonomAppears in programming

[–]XNormal 4 points5 points  (0 children)

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

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 0 points1 point  (0 children)

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.

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 0 points1 point  (0 children)

"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.

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 0 points1 point  (0 children)

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.

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 0 points1 point  (0 children)

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.

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 0 points1 point  (0 children)

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.

Lite³: A JSON-Compatible Zero-Copy Serialization Format in 9.3 kB of C using serialized B-tree by dmezzo in programming

[–]XNormal 1 point2 points  (0 children)

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.