ANSI Escape Sequences

Agreed, it's a confusing message.

ANSI Escape Sequences

The longer answer is that Nim is just passing through bytes; the terminal driver deals w/ Ansi escape codes. `\e` and `\x1b` are valid ways to get the control byte in Nim, but it doesn't accept escape sequences in octal, per the error message.

ANSI Escape Sequences

Use `\e` instead of `\033`

cannot open: /dev/stderr

What's wrong with `stdout.write(s)`? I'd totally forgotten about symlinks in /dev. You can always just write to fd #2 :)

how to feed stdin to external process and redirect stdout ?

If you like, see which is built on top of a flexible single-threaded IO multiplexing library, which includes a subprocess API that's even more flexible than Python's subprocess library. The one-shot call (below) gives you a much more flexible interface wher

NIR

Incremental compilation first, REPL second. The rest is all fine but would be much lower down my list.

AES Help Please

BTW, I see you're on windows; I only develop for Posix systems, and def don't test on wsl2, but OpenSSL should be there on windows. All you need from it are aes.nim and random.nim which are built only on OpenSSL, so you should be able to yank those two files out. I also used `strDump()` and

AES Help Please

First, you should never be using CBC mode for a number of reasons, including no tamper detection, and potential issues with padding attacks, such as ones that have hit TLS in the past. Instead, you should be using a more modern encryption mode that does integrity checking by default. NimCrypto

Explanation for SSL/TLS Error

I take it back, OpenSSL wasn't the issue, it was `-lc` (for `getaddrinfo` in particular) and `-ldl` (for `dlopen` itself). So calling either of these two functions in a static binary seems to result in the corresponding library being dlopened even if statically linked, at least according to the

Explanation for SSL/TLS Error

IIRC, that doesn't work for openssl 3, it still dlopens in all cases. There are other things like `getaddrinfo` and dlopen itself where Nim seems to require the dynamic library even if statically linking. It should be much easier to force static linking, and actually not have dynamic dependenci

Explanation for SSL/TLS Error

One should generally prefer OpenSSL3 to 1.1 anyway, but I agree it's painful. It also seems to be the case that OpenSSL must be dynamically linked w/ Nim due to it being dlopen()'d even if it's statically linked. We ended up doing some trickery to redirect the dlopen() call ourselves.

Explanation for SSL/TLS Error

Well, `SSL_get1_peer_certificate` only exists in OpenSSLv3. So it's likely that you somehow were compiling against OpenSSL 1.1 headers. It may be the case that you only have 1.1 installed; Nim can do either out of the box, but if you were looking for 3, but it wasn't installed, you'd get an err

crosscompiling - SSL

IIRC, OpenSSL, at least v3, gets dlopen()'d no matter what you do, which will then attempt to dynamically load things that are already statically linked. We played some low-level games to redirect the loader ourselves. The tech world uses static binaries heavily. It shouldn't so hard to get one

A seasoned programmer's take on Nim's docs

Being more feature complete might be a good reason to to support it, but it shouldn't preclude supporting what people know. And it's easy to have different definitions of 'failed'; very few new projects use RST and Markdown has become nearly universal with a massive ecosystem around it that is

A seasoned programmer's take on Nim's docs

@dlesnoff Some really good stuff in there. When I was thinking about fixing the problem, I was reminded that neither I, nor most people new to the community, know RST at all. In most environments, when people are documenting code for extraction, they're using markdown. I am not going to take the

A seasoned programmer's take on Nim's docs

Was thinking I should perhaps clarify even more. Informally, we know that, AES run in CTR mode is provably secure (which we can formally define). Security proofs come with assumptions / requirements, and here, we have a few that are mostly reasonable to achieve. The major assumptions include: Th

A seasoned programmer's take on Nim's docs

You are all missing the point of my benchmark, which was to get at the speed the raw ALGORITHM goes. It is SIMPLY one AES encrypt per 16 bytes of output. My approach was a back-of-the-napkin to show what my crappy machine does when there's very little overhead EXCEPT the encryption operation. B

A seasoned programmer's take on Nim's docs

BTW, another reason I used DD is because I didn't want to risk a smart enough compiler that knows reading/writing to /dev/zero is a noop optimizing it away, which would always end up over-reporting its performance :)

A seasoned programmer's take on Nim's docs

Coming onto a project that already exists is a lot different than selecting a language for whatever new µ-service is needed today. Nobody wants you to rewrite the code that is already there, but I have seen inside a large number of tech companies, and can tell you that, in 'big tech', language c

A seasoned programmer's take on Nim's docs

Thanks, thoughts below. > trying to be synthetic, but I have enjoyed the exchange, there is material to > untangle in multiple threads here. :) > on concepts: looking forward to your > write up! > on compiler errors: yep, they can get bad, with some experience > they become better to navigate,

A seasoned programmer's take on Nim's docs

In my experience, decisions on language choice in most of the big tech companies are generally bottoms up. The company often won't have any oversight on language choice. I've seen people in big tech companies consider not going with Rust because they were worried about the size of the talent poo

A seasoned programmer's take on Nim's docs

> I'd prefer to not have integration with proprietary commercial software as > part of the standard library. That's a reasonable concern for sure. Still, until the cloud providers find Nim important enough to ship their own SDKs, this is a MAJOR use case in the real world, and will be a real im

A seasoned programmer's take on Nim's docs

> Along those lines some specific actions that I think would be promising would > be: > > working towards a nim foundation (see previous discussion). A foundation > could foster the creation of specific official working groups on various > matters (documentation, ecosystem, funding, ...) and it

A seasoned programmer's take on Nim's docs

Hey there! I'm going to start with your ending, then go back up to the top. > Finally, there are enough breadcrumbs in your replies to make me guess > (without being afraid of an unintended reveal ;)) that your identity is John > Viega, correct? It is very nice to see an established industry pla

A seasoned programmer's take on Nim's docs

> > Ideally, someone compiles a numbered list from this thread with actionable > > issues or action items and we create an issue/documentation roadmap from > > this. > > What I'd suggest is a #docs (and a #bugs) room in discord. Even if everyone's > not there, it serves as an easily searchable

A seasoned programmer's take on Nim's docs

> > for trying to make people talk to each other in a more respectful and > > professional way > > This is a statement about your intentions behind making your post. My > statement is about your post itself. The thread's about documentation. Did > your post concern documentation? Your intention

A seasoned programmer's take on Nim's docs

> > the comments there, to me, read as hostile to people wanting more docs. > > There is no "anti-more-docs" faction. Not in that thread, or this one. Nobody > will obstruct you from writing docs, nor retaliate if you write docs. Nobody > will be sad if you write docs. You won't see an end-of-ye

A seasoned programmer's take on Nim's docs

I "liked" his post, because it seemed like an objective assessment that aligns with my assessment. I'm here because I love the language, want to see it win, and wanted to understand what it would take to drive more adoption, especially since, as someone else mentioned, there does seem to be some

A seasoned programmer's take on Nim's docs

Well, I believe I suggested that a doc wiki was a good idea. My intent wasn't so much to get anything specific done doc-wise, but to help people understand that, no matter what you think about the docs, they're probably a barrier to adoption for many... because it's clearly not been seen that w

A seasoned programmer's take on Nim's docs

The whole point is that plenty of people are NOT going to help improve the docs, and a lot of those people are people that I'd think people would welcome as Nim users. If accelerating adoption isn't a goal, then there's nothing to do. But assuming it is a goal, the question is, what are the mos

A seasoned programmer's take on Nim's docs

I'm not suggesting anyone improve anything. I'm just trying to point out that, if there are doc complainers, it is because there is an actual barrier, and that barrier is almost certainly keeping people out of the tent that you want in the tent. I don't think the doc for getAppFileName is _conf

A seasoned programmer's take on Nim's docs

I suspect the thread I saw got locked because people might not want to discuss the docs. Clearly a lot of work has been put into them, and I do think they're pretty broad. The documentation feels sufficient in most areas for grey beards coming from C like myself; I picked up the language less th

Async Socket with SSL Context throws "error:1420C114:SSL routines:ssl_write_internal:uninitialized"

Did you compile with -d:ssl?