GraphQL?

now we have a graphql implementation in Nim . it works with `query` and `mutation` part of graphql, have a nice API for custom scalar and simple resolver interface. shipped with a http server, a playground http server, and a http client. features that

How to create const object of non-root object type

That PR is at odds with which I consider to be much more important -- consts in general should have "no inlining" semantics, this is important for embedded systems, if you are happy with template-like expansions instead, you can simply use a template

Employment Opportunity - Systematic Trading

Neat! A lot of really talented Nim devs here; hope you find someone.

XML parsing performance

I vote for staying with `-d:debug`. You debug a program much more often than release it. And most compiled languages do it like this.

How to create const object of non-root object type

Wow, looks great, love it!

[ANN] Nim0, a playground to learn compiler internals

If you want to understand how Nim compiler works, start by looking under the hood of the Nim0 compiler, a Nim-compatible toy language with a compiler and an emulator for a RISC CPU. This project is much smaller than the Nim compiler, everything being packed in 5 Nim files. But most important is

How to definitely free memory of seq?

yes, see my edit. you need to preallocate your seq with `newSeqOfCap`

Employment Opportunity - Systematic Trading

SESCO, a commodities (largely electricity) proprietary trading firm, is looking to hire Nim programmers! Unlike many other markets, electric supply and demand must be instantaneously matched. As a result, market operators (called [ISOs/RTOs](https://en.wikipedia.org/wiki/Regional_transmission_o

XML parsing performance

IMHO it -d:debug stays the default the final message should very clearly and explicitly mention -d:release. However my vote is to change the default to -d:release as @Araq suggested. Experienced users can always shift to -d:debug when needed.

How to definitely free memory of seq?

It works to some extent. But even in place the seq sometimes needs to reallocate a new array. Then the old array gets neglected. For example I have a seq of length 140 million. Now I want to make a new seq of size 240 million. It allocates a new memory region of size 240 million because it would

What to use instead of TaintedString?

The basic idea of `TaintedString` is that refers to a regular `string` that was received that could potentially have "bad" data, for example like user input, a file etc. It was a mode the could be set at compile-time to distinguish between `TaintedString` and `string` so that you would be mistak

nint128 - 128-bit integers

I came to announce my package [nint128](https://github.com/rockcavera/nim-nint128), 128-bit integers. It is not yet 100% (the basics are done), but it is already quite usable. The intention of the package is to always try to achieve the best possible performance. I am currently testing on amd6

How to definitely free memory of seq?

Try making your func work in-place.

XML parsing performance

> Hmm, looks like opt:speed might interfere with debugging can you show such example (ideally reduced) ? I could see how that would be the case with `-d:nimStackTraceOverride --import:libbacktrace --debugger:native` (see also: `--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls"` refs

XML parsing performance

Hmm, looks like `opt:speed` might interfere with debugging. Maybe we could have a new optimization flag for increasing speed of debug code? There's a gcc flag called `-Og` that increases speed without hindering debugging. From [here](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) > -

XML parsing performance

@Araq is there any reason we can't have `--opt:speed` for regular debug builds? Using the code from OP yields this: # DEBUG nim c -r g.nim # Time taken: 14.058434 Run # DEBUG with --opt:speed nim c -r --opt:speed g.nim # Time taken: 3.76424

unzip multipart zip file

You need to concatenate all of the zip files into one file first, then extract that. See [here](https://unix.stackexchange.com/questions/40480/how-to-unzip-a-multipart-spanned-zip-on-linux)

How to create const object of non-root object type

it works with which should've been merged long ago, IMO when defined case2: type A {.inheritable.} = object a0: int type B = object of A b0: int type C = object of RootObj c0: int cons

XML parsing performance

On its own line character cells aren't so expensive that both is very chatty. I had mentioned `SLOW, DEBUG MODE` which might be better spelled `***SLOW, DEBUG MODE; See manual/etc.***`..

How to definitely free memory of seq?

yep, `setLen`

unzip multipart zip file

Failing how? Failing to see the files as zip files?

How to definitely free memory of seq?

`large_thing1 = large_thing_2` logically requires that for a brief moment they both exist at the same time. modify `hashtable` in-place instead of creating a new one and sinking it over.

How to definitely free memory of seq?

Is there something similar to "std::vector::resize" from C++ for seq[T]? I didn't find anything, but maybe I looked at the wrong places.

XML parsing performance

Coloring the word "Debug" helps, however, maybe we need a better term. "SLOW"? Any better ideas?

How to definitely free memory of seq?

I can't test the minimal example I posted here, but the regarding the seemingly non released memory the real code behaves identical on Windows. When I use /usr/bin/time I get "Maximum resident set size (kbytes): 263504". The program is a chess engine that isn't allowed to use excessively more RA

Qualify identifier with exported module?

This is the right solution. Do an include of a file which holds common imports. If `gdnim.nim` only imports and exports modules, you could remove the exports and just `include gdnim` instead of `import gdnim`. This will drop those import statements into the source file you included from allowing

How to definitely free memory of seq?

Your OS/libc may or may not release the virtual memory pages back to the free pool and so show it as still part of the resident set size. glibc on Linux _should_...Sometimes things like `/usr/bin/time` will tell you only "peak RSS", not current. Similarly, htop may look at something else. Linux

XML parsing performance

Thanks, @GamzWithJamz. Color certainly can make things pop, and I've also personally spent quite a bit of [time](https://github.com/c-blake/lc) [tweaking](https://github.com/c-blake/procs) [colors](https://github.com/c-blake/hldiff) and have some generic support for run-time colors in [cligen](

How to create const object of non-root object type

I don't believe you can. Nim seems to have a fundamental problem with child object types and constness. This shouldn't be impossible to enable, but maybe there is a good reason for it?

server/client test, using testament

I'm using this to test asyncnet sockets proc simulateAsyncClientServer*(function: (AsyncSocket, AsyncSocket) -> void) = let ssocket = newAsyncSocket(AF_INET, SOCK_STREAM, IPPROTO_TCP) let rclient = newAsyncSocket(AF_INET, SOCK_STREAM, IPPROTO_TCP) var sclient:

How to create const object of non-root object type

Since const is available at compile-time, maybe this is a limitation from NimScript? Info about that is [here](https://nim-lang.org/docs/nims.html).

some sizeof results

relevant issues: * [`array[0, T].sizeof` incorrect · Issue #14786 · nim-lang/Nim]() * [CT sizeof(T) is wrong if T or any member is empty object · Issue #13945 · nim-lang/Nim](https://github.com/nim-lang/Nim/issues/13945) * [sizeof for importc e

XML parsing performance

I really appreciate the sort of "banner" feeling I get from that line. It contains a bunch of information important for the whole compile, but in a very visible manner. The current hint line is very hard to notice, especially if you configure file watches that trigger nim compilations. My termin

How to definitely free memory of seq?

When using `htop` I look at "residentual memory". When I use `-d:useMalloc` it shows not 128MB as expected or 260MB like before, it shows 1504 bytes.

XML parsing performance

How to definitely free memory of seq?

How do you measure the memory consumption? Also try with `--gc:arc -d:useMalloc`

How to definitely free memory of seq?

It doesn't change the behavior. I am using Nim 1.4.6 and compiling with `nim c -d:release --gc:arc --run main.nim`

How to definitely free memory of seq?

Use `--gc:arc` and Nim version 1.4.x or later.

NimConf 2021

After a very successful first incarnation of NimConf, which was held online on June 20th 2020, it is time for another one! We will keep the last year's format where the talks are pre-recorded and the authors participate in live chat with the audience. The talks can be anywhere between 10 and 45

How to definitely free memory of seq?

I have this little program where I basically create a new seq with many entries and then reassign a new seq of big size to the same variable. What I want is that the program then doesn't use the memory from that first sequence. But when I look with htop for the memory usage, it show that the pro

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

Hi r3c, actually it's not possible to install the official nim 1.4.6. windows distribution if you (like perhaps ALL existing windows users) have windows defender as antivirus active. I guess you don't care, because I guess you do not use windows. Well, laugh like you want, this attitude and a

What to use instead of TaintedString?

string seems fine in my use case. I had looked here: and it didn't have any advice, unlike other deprecated items. Perhaps the answer is considered too simple to need explanation! But in truth I had adapted that from something else and did not really

unzip multipart zip file

Hi all, I'd like to unzip some multiple zip files ( xxx.zip.001, xxx.zip.002, etc) that I've created using 7zip splitted in small file sizes. I am using the following code: for kind, path in walkDir "C:\\tmp\\testzip": if "zip.001" in path: echo path

How to create const object of non-root object type

` type A {.inheritable.} = object type B = object of A type C = object of RootObj const r = RootObj() const a = A() #const b = B() # Error: invalid type: 'B' for const #const c = C() # Error: invalid type: 'C' for const ` Run

Error when building for JS - internal error

The JS code generator does not support "UncheckedArray".

XML parsing performance

> Is there a list of checks anywhere with information about what the different > build modes enables/disables? You can read config/nim.cfg, it contains: @if danger or quick: obj_checks:off field_checks:off range_checks:off bound_checks:off overflow_chec

Error when building for JS - internal error

I'm making a (desperate) attempt to build the whole project with the JS backend, and with verbosity set to maximum, I've managed to track down pretty much all of the errors. Now, I'm stuck with this one: /Users/drkameleon/.choosenim/toolchains/nim-1.4.6/compiler/sempass2.nim(208,

XML parsing performance

> that message should be the last thing you see when you compile; it should > stand out I agree being the last line of all the various output is another way to make sure people read it. However, it actually is already either the last or very close to the last. :-) I think it is really worth a

XML parsing performance

Is there a list of checks anywhere with information about what the different build modes enables/disables?

XML parsing performance

I understand that embedded environments are constrained. But, nowadays, this is more for an economical reason than for a technical reason. More memory means that each unit costs more and when you want to sell millions of units, this is indeed something to take in consideration. But this positio

XML parsing performance

> -d:danger shrinks the entire binary to approx 10Kb. I will soon write a > little bit about it Please do that, yes. However, one can also try with `--checks:off --indexChecks:on`. Integer overflows by themselves do not cause buffer overflows.

XML parsing performance

-d:danger is essential for embedded environments. newlib nano with nim is around 30Kb in release-mode (arm target, default toolchain - nim gc arc ). -d:danger shrinks the entire code to approx 10Kb. I will soon write a little bit about it|

XML parsing performance

The problem with the debug mode is that, for people who never used languages compiling to native code, it doesn’t explicitly states that in this mode programs will be considerably slower. Many will think that the program will be bigger (containing debugging data) which is true indeed, but will n

XML parsing performance

> the fact that there are 3 modes is a little confusing gcc has >500 compiler flags

XML parsing performance

`-d:release` is a good default, good performance, no compromises on safety. `-d:danger` is for the people who know what they are doing. It makes no sense to make `danger` the new default, I hardly ever use it myself fwiw. It's a terrible performance/safety tradeoff. Our goal should be to ensure

XML parsing performance

If we are going to rely on a message to help people get the most performance from their builds, that message should be the last thing you see when you compile; it should stand out (make it its own message, use a different color, etc.); and it should tell you something like "use -d:danger for max

some sizeof results

PRs are always welcome.