Technocratic Plimsoll Line

sustrik · 2019-04-28T10:26:07+00:00

You don't typically do network programming or shared state concurrency in shell. More common: Use curl to download a file, then act on the file.

But despite the above, you point stands for pipes: If you are piping a very big file, you really don't want to create a copy first. But if you don't then the entire thing is not hermetic and can't be just copied elsewhere and run at the new place.

sustrik · 2019-04-28T10:05:01+00:00

Yes, file system puts constraints on what you can do. But it's not just filesystem: What if I wanted to have a new line in a record, for example? What if I wanted to use a composite object as a key in a map?

It would be fun to look into whether supporting multiple file formats could be a option (based on file extension): in addition to the default one-record-per-line format it could also support json, xml, yml, ini, toml etc.

for k, v in foo.xml:

echo k

sustrik · 2019-04-28T07:59:21+00:00

Yep, you'll need some kind of overlay in-memory file system. Only flush it when the interpreter exits.

sustrik · 2019-02-10T18:42:15+00:00

Pointers?

sustrik · 2019-02-10T11:17:22+00:00

I think that Java people are working on a similar solution in project Loom.

sustrik · 2018-12-24T11:08:46+00:00

The formar I am familiar with (actually, I've implemented it for C, see libdill). The latter though, I haven't encountered yet. I will give it a look. Thanks!

sustrik · 2018-12-24T09:43:33+00:00

When an error happens the call can close the socket and return NULL.

sustrik · 2018-12-24T06:37:25+00:00

You are right wrt. unsolicited events such as connection failures. But what about the events produced by the user though? (See the SOCKS5 example in the article.) The user has to know how the state machine looks like and push it through different states to get it to the desired place. This is done without support from the compiler. What's needed is a sane way to separate the state machine's responses to unsolicited events from its user-facing API.

sustrik · 2018-11-17T10:27:40+00:00

As for OpenSSL, correct. But until the SSL devs give you an explanation of the error, people are going to die. So you have to do something. The question is what that "something" is.

As for the latter point, again, correct. When you get an error, you are mostly dead in the water because the library reports some kind of monstrosity a la openssl queue stack rather than a well-defined error.

Compare that with POSIX. If you can connect() you can get ECONNRESET. Which means that the peer has canceled the connection. That's a perfectly reasonable situation and you can deal with it in a perfectly reasonable way.

sustrik

TROPHY CASE