Why I left the Nim community

At this point in Nim’s life, in my opinion there should be a concerted effort to stabilise the standard library and the compiler rather than adding anything more. There are so many features and switches and toggles that even if you look away for a month or two there’s something totally new or di

print dates in reversed order

If you know the number of entries up front, you can also do something like this and pre-allocate the sequence: import times, algorithm const limit = 3 let today = now() var sq = newSeq[string](limit) for i in 1..3: var duration = initDuration(days = i)

IRC freenode staff exodus

> As a curiosity, thanks to this event, I found out that ddevault (the creator > of sr.ht) has been lurking around nim's irc in the last months > > I would say this last bit at least is good news! We use builds.sr.ht for FreeBSD and OpenBSD CI, he's probably been lurking due to our excessive re

User feedback needed about synchronization primitive call once

I haven't actually tested the library in a while now, and Nim has a habit of changing. Last time I did check was with Nim 1.2.6, and we're now up to 1.4.6 so things may have changed. I would also read the pthread docs the same way personally, with `deinitLock` being unsafe if `initLock` hasn't

User feedback needed about synchronization primitive call once

There was a thread on this very topic a while back, but I can't for the life of me find it now. At the time, I created the following library:

Make `std/asynchttpserver` more robust?

I would agree with some form of error handling, but it may be better as a callback that's passed when creating the server - that way it can be handled however the consumer wishes.

use jester with SSE (server side event) example

Unfortunately detecting client disconnects isn't particularly easy with SSE, given that it's a one-way communication channel (unlike WebSockets which are two-way). Even just talking about disconnects, there are several different types of disconnect that can happen such as: 1. The `EventSourc

use jester with SSE (server side event) example

The `isClosed` procedure only returns true if the socket has been closed on the local side (e.g. in your Nim code you've called `close` on the socket). It does not detect the remote end having been closed.

Is there an easy way to bake in parameters at compile time?

`static` parameters with `static` blocks are great for doing this kind of work at compile time in my experience. I actually [wrote a blog post related to this](https://www.euantorano.co.uk/posts/compile-time-string-validation/#approaching-the-problem-in-nim) a while back.

Improving BSD support - NetBSD

We're now down to a bunch of errors with the boehm GC (which may be related to the package on NetBSD, or may be down to TLS emulation - I still need to debug further) and `tests/stdlib/tfdleak` which is due to what seems to be a bug within NetBSD. Current failures: 11:47:29 Categor

Hacktoberfest is here!

And now they've changed the rules so that repositories must have a specific label before PRs against them re counted: \- which is probably for the best, honestly.

Improving BSD support - NetBSD

The `tgetprotobyname` failure is now fixed by this commit: I'm currently setting up a Jenkins server running NetBSD with an aim to build at least once a day on the platform at first, then in the future look at get

Improving BSD support - NetBSD

m(108) nimhcr_unit /home/euant/src/Nim/lib/nimhcr.nim(346) hcrRegisterProc /home/euant/src/Nim/lib/pure/reservedmem.nim(223) setLen /home/euant/src/Nim/lib/pure/reservedmem.nim(97) setLen /home/euant/src/Nim/lib/pure/includes/oserr.nim(94) raiseOSError Error: unhandled exception: Permi

Should a function that's called many times return Table or ref Table?

There's nothing as far as I'm aware of in the stdlib like `call_once`, but something like the following seems to work: import atomics when compileOption("threads"): import locks when compileOption("threads"): type OnceBase = object of RootObj don

io2 module in stew

Not using `FILE` for file processing is perhaps my favourite bit. Also looks like there's some consideration of [#12327](https://github.com/nim-lang/Nim/issues/12327), which is great to see as I've ran into a few issues over the years that stem from it.

Improving BSD support - NetBSD

Yep, that seems to do the trick. I ran the following from the command line: > nim c -r tests/gc/gcleak2 C -d:release --gc:boehm --tlsEmulation:off Hint: used config file '/home/euant/src/Nim/config/nim.cfg' [Conf] Hint: used config file '/home/eu

Improving BSD support - NetBSD

Cheers, I'll give that a go and see what happens - wouldn't have thought of that!

Improving BSD support - NetBSD

I've now ran the core dumps through gdb to get backtraces for them all in case somebody else has any insight into the causes: **cyclecollector.core** > gdb ./tests/gc/cyclecollector cyclecollector.core Reading symbols from ./tests/gc/cyclecollector... (No debugging symbols f

Improving BSD support - NetBSD

pected --- exitcode: 0 - Given exitcode: 1 Output: nimhcr_unit.nim(108) nimhcr_unit /home/euant/src/Nim/lib/nimhcr.nim(346) hcrRegisterProc /home/euant/src/Nim/lib/pure/reservedmem.nim(223) setLen /home/euant/src/Nim/lib/pure/reservedmem.nim(97)

Improving BSD support - NetBSD

In case anybody else wishes to run the tests on NetBSD, there are a few steps to go through (these steps assume you are logged in as root): pkgin install git \ sqlite3 \ sfml \ mozilla-rootcerts \ boehm-gc \ gmake \ nodejs \ pcr

HttpClient with UNIX_AF/SOCK_STREAM Socket instance

.net allows passing a HttpMessageHandler to the HttpClient constructor. The handler is responsible for sending a request: [https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpmessagehandler?view=netcore-3.1](https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpmessagehandle