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

Today, version 1.0.0 adds structured pipelines: a mechanism to exchange (almost) arbitrary objects via POSIX pipes, and transform them via external programs, shell builtins or Scheme code.

Example:

  dir /proc | where name -starts k | sort-by modified

  ┌───────────┬────┬───────────────┬────────┐
  │   name    │type│     size      │modified│
  ├───────────┼────┼───────────────┼────────┤
  │kcore      │file│140737471590400│09:32:44│
  │kmsg       │file│              0│09:32:49│
  │kallsyms   │file│              0│09:32:50│
  │kpageflags │file│              0│10:42:53│
  │keys       │file│              0│10:42:53│
  │kpagecount │file│              0│10:42:53│
  │key-users  │file│              0│10:42:53│
  │kpagecgroup│file│              0│10:42:53│
  └───────────┴────┴───────────────┴────────┘

  ip -j route | select dst dev prefsrc | to json1

  [{"dst":"default","dev":"eth0"},
  {"dst":"192.168.0.0/24","dev":"eth0","prefsrc":"192.168.0.2"}]

This allows arbitrary transformations at each pipeline step: filtering, choosing a subset of the fields, sorting with user-specified criteria, etc. And each step can be an executable program, a shell builtin or Scheme code.

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

Comments URL: https://news.ycombinator.com/item?id=47397840

Points: 30

# Comments: 5

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

In my case, I use my interactive shell https://github.com/cosmos72/schemesh every day as login shell.

You can look at it as heavily customized Scheme REPL, where everything not inside parentheses is parsed and executed as shell syntax, and everything inside parentheses is parsed and executed as Scheme syntax.

Having arithmetic and procedure definition within the login shell definitely feels liberating, at least to me

As I wrote above, I am debugging it and fixing some known issues, thus truecolor support is not yet in the default branch

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

Short of hand-coding "which terminal supports which variant" I do not know any standard mechanism to detect that (beyond the well-known $TERM=...-256color and $COLORTERM=truecolor or $COLORTERM=24bit)

I guess I'll have to add command line options to choose among the variants 1...7 you helpfully listed above.

My main use it to render twin directly on X11, which avoids all these issues, and while rendering inside another terminal is important and is not going away, I am OK with a few minor color-related limitations (note: limitations, not bugs) in such setup, especially if the other terminal does not follow the relevant standards

I've been using Twin as my everyday terminal emulator and terminal multiplexer since ~2000, slowly adding features as my free time - and other interests - allowed.

As someone pointed out, the look-and-feel reminds Borland Turbo Vision. The reason is simple: I started writing in in the early '90s on DOS with a Borland C compiler, and I used the Borland Turbo Vision look-and-feel as a visual guideline (never actually looked at the code, though).

The porting to linux happened in 1999 (it was basically dormant before that), and Unicode support was progressively added around 2015-2016 (initially UCS-2 i.e. only the lowest 64k codepoints, then full UTF-32 internally, with terminal emulator accepting UTF-8). There are still some missing features, most notably: no grapheme clusters, no fullwidth (asian etc.) support, no right-to-left support.

Right now I'm adding truecolor support (see https://github.com/cosmos72/twin/tree/truecolor) - it's basically finished, I'm ironing out some remaining bugs, and thinking whether wire compatibility with older versions is worth adding.

And yes, documentation has been stalled for a very long time.

Retrospectively, I should have switched C -> C++ much earlier: lots of ugly preprocessor macros accumulated over time, and while I rewrote the C widget hierarchy as C++ classes, several warts remain.

In particular, you should do the `switch op` at https://github.com/skx/simple-vm/blob/b3917aef0bd6c4178eed0c... outside the closure, and create a different, specialised closure for each case. Otherwise the "fast interpreter" may be almost as slow as a vanilla AST walker.

Here is a pseudocode example, adapted from gomacro sources:

https://gist.github.com/cosmos72/f971c172e71d08030f92a1fc5fa...

This works best for "compiling" statically typed languages, and while much faster than an AST interpreter, the "tree of closures" above is still ~10 times slower that natively compiled code. And it's usually also slower than JIT-compiled code

There are more tricks available there, as for example unrolling the loop that calls the list of closures, and having a `nop` closure that is executed when there's nothing to run but execution is not yet at the end of the the unrolled loop.

It would be quite limited:

internal status would not persist between invocations,

and it would only be able to exchange unstructured data (a stream of bytes) with the shell

In shells, "test" and "[" are often used after "if", as for example

  if test -f "some_file"
    do_something
  fi

  if [ "$FOO" != "" ]
    do_something_else
  fi

  (if (file-regular? "some_file')
    (sh-run {do_something}))

Also, "test" implements a mini-language full of one-letter operators: `-f FILE` `COND1 -a COND2` `COND1 -o COND2` etc.

I really don't miss it, as I find the equivalent in Scheme to be more readable - and of course more general

  (file-regular? "FILE")
  (and COND1 COND2)
  (or COND1 COND2)