cosmos0072

Yes. Initially, I wanted to integrate http client, sqlite client etc. directly in the main shell executable.

This turned out to be impractical, because it introduces compile-time dependencies on external libraries, and because any bug, vulnerability or crash in the C code would bring down the whole shell.

My current solution is to have separate C programs (currently `http` and `parse_sqlite`) that are not compiled by default: you need to run `make utils` to build them.

> But does that mean I can produce a Schemesh binary that will include Chez Scheme and run my script on any Linux or FreeBSD host?

Yes, exactly. Schemesh is a C program that includes both Chez Scheme REPL and shell features.

> If you know nushell, they will feel familiar as they are inspired by it - the implementation is fully independent, though.

Looking deeper, there are two main differences:

- Nushell structured pipelines are an internal construct, and only work with nushell builtins. Schemesh uses actual POSIX pipes, which allows to also insert executables in the pipelines.

- schemesh also allows to insert arbitrary Scheme code in the pipelines. Nushell does too, in a sense: you have to write nushell language though

Examples: most children believe in the same religion as their parents, and can visit friends and places only if/when allowed by their parents.

This is simply extending the same level of control to the internet.

Government-mandated restrictions are completely another level.

My stance is that if somebody is a minor, his/her/their parents/tutors/legal guardian are responsible for what they can/cannot do online, and that the mechanism to enforce that is parental control on devices.

Having said that, open-source zero-knowledge proofs are infinitely less evil (I refuse to say "better") than commercial cloud-based age monitoring baked into every OS

Other single-key bindings I use often are:

KP* executes 'ls'

KP- executes 'cd -'

KP+ executes 'make -j `nproc`'

If, as stated, accessing one register requires ~0.3 ns and available registers sum up to ~2560 B, while accessing RAM requires ~80 ns and available RAM is ~32 GiB, then it means that memory access time is O(N^1/3) where N is the memory size.

Thus accessing the whole N bytes of memory of a certain kind (registers, or L1/L2/L3 cache, or RAM) takes N * O(N^1/3) = O(N^4/3).

One could argue that the title "Memory access is O(N^1/3)" refers to memory access time, but that contradicts the very article's body, which explains in detail "in 2x time you can access 8x as much memory" both in text and with a diagram.

Such statement would require that accessing the whole N bytes of memory of a certain kind requires O(N^1/3) time, while the measurements themselves produce a very different estimate: accessing the whole N bytes of memory of a certain kind requires O(N^4/3) time, not O(N^1/3)

Especially when I have to familiarize with code written by someone else, I usually start by "cleaning" it - small refactorings such as splitting overlong functions and simplifying expressions, that are trivial to prove as correct even without a deep knowledge of the code purpose.

Only when the code looks sufficiently clean and familiar, I start adding the requested new features

I will have a look too, the terminal should not crash or stop being responsive