UPDATE: the production facilities seem to be closed; only office buildings remain somewhere.

Per Wikipedia [1], Lucent's factories and offices are^W were situated in places like Murray Hill and Mount Olive, NJ, North Andover, MA, Reading, PA, and a bunch of other places in the US.

I think it makes^W made Nokia, which owns Lucent properties, "more US" than, say Ericsson and Samsung, until these facilities were closed.

[1]: https://en.wikipedia.org/wiki/Lucent_Technologies#Divisions

Consider: "Artificial two-star General intelligence".

I mean, once they "reach AGI", they will need a scale to measure advances within it.

Well humans at that point probably won't be able to adequately evaluate intelligence at that level so the AIs will have to evaluate each other.

I'd say that it's generally unwise to use fixed-width integers in a data structure where this width can vary widely, and has no logical upper limit. Arbitrary-size integers are well known, used in practice, and not hard to implement.

Even if it's "generally unwise" it was a well-thought decision in this particular case. See my other comments. An array of elements with constant size is indexed for free. An array of elements of varying size needs a separate index. SICK's binary representation (EBA) was created with several particular usecases in mind. I needed most compact representation and fastest access (for very underpowered devices), large objects were not a big concern-they can be chunked externally.

For indexes, I completely agree!

If I were to add support for larger amount of keys, I probably would introduce two versions of the data structure, with 16-bit and 32-bit indexing. And, maybe, 8-bit indexing for tiny amounts of keys. But that would definitely complicate the design, and should be done only when there's a real need.

Every such decision is a trade-off; I think yours is fine.

I guess that can even be done without breaking the format. I may introduce Obj32 table and maintain backward compatibility. But I'm not sure that's necessary, external chunking works just fine.

Shameless plug: I made this userstyle to make HN comfortable to handle both on desktop and mobile. Minimal changes (font size, triangles, tiny bits of color), makes a huge difference, especially on a mobile screen.

https://userstyles.world/style/9931/

Thanks for that, it works well, and I like the font choice! Though personally I found the font-weight a bit light and changed it to 400.

The word "micron" is a common unit of measurement (μm). The trademark Micron™ only applies to microelectronic hardware, I suppose.

I hope you are correct, but probably continuing the discussion usefully would require doing a trademark search.

They also have a Micron trademark for software, as they sell some software packages. So it's really just a question of whether or not they notice and decide to go after you.

Wren, the topic of the post, is positioned as a descendant of Smalltalk, the most OOP language of them all. The author clearly finds the OOP paradigm important.

This reply was wrong, removed.

Please downvote it to oblivion.

Every major CPU ISA still in use can, in fact, address individual bytes (C and C++ standards even demand atomic access).

It's just inefficient, but sometimes needed (MMIO, inter-cpu visible byte changes, etc)

C and C++ standards demand atomic access to individual chars.

It is not a given that a C/C++ char is a "byte" in the conventional modern understanding of that word, though. sizeof(char)==sizeof(bool)===sizeof(int)==1 is a perfectly valid arrangement for an architecture that is only capable of addressing machine words, and there have been such architectures historically although I'm not sure any are still around today.

Don't modern C and C++ standards mandate an 8-bit char now though?

EDIT: never mind, guess I misremembered! it's just mandated to be at least 8 bits

OTOH gio-based WebDAV access built into Nautilus and Thunar is something I use daily, and it works quite fine, for a FUSE-based filesystem.

Unlike NFS or SMB, WebDAV mounts do not get stuck for a minute when the connection becomes unstable.

What else would you expect, just out of curiosity? SMB? NFS? SSHFS?

A proprietary binary patented protocol...

and do what, implement virtual filesystem driver for every OS ?

Only if adding that complexity locks in more subscribers for premium features and support.

A PR can be broken, or not. If it's not broken, you approve it. You offer all the advice on how to improve it, and promise to re-approve promptly if these improvements are implemented. But you suggest it, not demand it.

If the PR is broken, you clearly denote where is it broken. I usually start comments to lines requiring changes with a red circle (U+1f354), because GitHub code review UI lacks an explicit way to mark it. You explain what needs changing, crucially, why can't it remain as is, and ideally suggest ways to fix it. Then you demand changes to the PR.

Because yes, your job is to gatekeep the codebase, protecting it from code that will definitely cause trouble. Hopefully such cases are few, but they do occur, even to best engineers at best engineering orgs.

The approver of a PR shares some responsibility in the case where the code causes production issues.

So look at the code and decide if you're willing to defend it if someone says, "Who approved this for production?" If you did your due diligence, thought the tests and the code were reasonable but some obscure interaction caused problems, you didn't have a way to know that.

If the code is just full of bad code smells and that's what blew up, then your defense is flimsy.

Production issues will happen. But they should always be the confluence of two or more errors resulting in a bad situation. Single cause failures are inexcusable.