Incorrect example in documentation for Return statement?

link: search for proc returnZero(): int = # implicitly returns 0 Run I get error message: Error: invalid indentation 1.4.6/config/nim.cfg' [Conf]

Incorrect example in documentation for Return statement?

I do not think that example is supposed to be runnable, but if you must you can make a PR and replace that code with. proc returnZero(): int = ## implicitly returns 0 Run or proc returnZero(): int = discard # implicitly returns 0

4th Nim online meetup

> yes, we break code when changing the major version from 1.x to 2.x which is > to be expected. Does it mean that all nimble modules that currently importing `json` will not be compiled in Nim2? This sounds really terrible... IMO, stdlib should employ stability index like `this

Let's Make Async Great Again!

I thought Weave was for parallelism, not for concurrency?

4th Nim online meetup

> we break code for the people who import json2 from Nimble once it moved into > the standard library (because the Nimble package then becomes outdated) well the code does not break, it just does not receive updates. > then we break the code for the people who import json because eventually it

concatenate byte

`string` and `char` can contain non printable bytes, including 0x00 Your problem here is `$data` == "[65, 66]" You could overload $ for openArray[byte] or just use a string in the first place let a = '\x41' let b = `\x42` let data = a & b Run

4th Nim online meetup

So we break code for the people who `import json2` from Nimble once it moved into the standard library (because the Nimble package then becomes outdated) and then we break the code for the people who `import json` because eventually it changed its meaning. I don't like it.

4th Nim online meetup

Ok I see the rejected RFC: And also a new one by Pmunch: I agree more or less with the picture sketched by @kaushalmodi: * a new json (better but with different api) starts as a nimble package. People

concatenate byte

Hello I would like to concatenate 2 inputs bytes (or more) like: var a: byte = 0x41 var b: byte = 0x42 var data = [a, b] Run And then transmit these into a post request: let client = newHttpClient() let body = data response = client.reques

4th Nim online meetup

> someone mentioned a RFC but I cannot seem to find one There was a rejected RFC from me, but I meant to encourage participants to write a new one. Sorry for the confusion.

4th Nim online meetup

About the versioning of stdlib modules, would this work (a different idea than what I brought up in the meeting): * The stdlib will still have one json.nim * The newer library should have all the features from the older json.nim even if the API is changing. People should not need to have t

4th Nim online meetup

I joined the meeting late but there was on interesting conversation on how to evolve stdlib (starting from the example: there is a faster json than the one in stdlib, but with a different api, how can we make it available in stdlib?). Is there a place where this discussion is ongoing? (someone m

nDustman (random URL generator)

Version 0.04 is live. Finally, you can configure scan right within main windows (no more editing ini file), there are brand new URL generation mask and all found links are now check through HTTP header request. Am I cool yet ?

nim-1.4.6_x64.zip/bin/nimble.exe reports as Trojan:Win32/Zpevdo.B

Hello, today Windows 10 Defender reported this; it shows up only on 1.4.6. A colleague also reported the same; he said that this issue did not happen on nim 1.4.0.

Let's Make Async Great Again!

To clarify my remarks: Async means lots of things: * The event loop mechanism. * The `async` macro transformation which maps async to Nim's closure iterators. * The `Future[T]` design. CPS is an alternative to our closure iterators and all the rest could remain the same or be improved

Let's Make Async Great Again!

The thing with Nim async is that it is just a library just like any other. All the async stuff is just clever macro transformations into closure iterators and IO polling. As such it needs to live within the limits of that system, such as the `{.async.}` pragma which is what actually transforms t

Preferred mingw version to build nim on Windows

It seems that libs from renew more frequently - more than once in half-year vs once in 5 year (TDM) and that means more modern cpu instructions and OS system intrinsics.

Let's Make Async Great Again!

> The future lies in and > . I've said it many times, if CPS requires > compiler support to be really usable, so be it. Please join these efforts! Yes, these are long-term strategic goals. My suggestions are more like short-t

Let's Make Async Great Again!

The future lies in and . I've said it many times, if CPS requires compiler support to be really usable, so be it. Please join these efforts!

Let's Make Async Great Again!

Seems like we have to live with `async`, let's think if we can improve how it's used. I [used Nim async](https://github.com/al6x/nim/tree/main/nodem) and it looks to me, compared to the experience of Async in JavaScript, there are couple of things could be improved. 1 Use same `await` instead o

4th Nim online meetup

A small reminder, this meetup will be held when this comment is 4 hours old.

server/client test, using testament

Is there a guide for running multiple threads?