Speeding up compile times

You can also use dynamically linked libraries in Nim to reduce compile times. For your libp2p example it could probably be greatly sped up by compiling the libp2p portion into a dynlib. I think you could use this technique

Tcp buffer reuse for lower memory use

The stdlib does provide methods to read data into existing buffer's. I've used it a fair bit on embedded devices, though mostly non-async. The easiest way to structure it in Nim to prevent copying I've found is to pass the buffer as an openArray parameter. Unfortunately the net functions don't

Nimforms - A simple GUI library for Windows

I love your small wrappers of user32

Tcp buffer reuse for lower memory use

Oh yeah, in a thread about HTTP servers recently, someone mentioned how asyncnet buffers reads. That same person had a patch back in 2017 to avoid doing that, here's the patch if it's useful to you

Tcp buffer reuse for lower memory use

My bad, I misunderstood. I will say that my original comment about C still holds true; you can interface directly with the kernel. My assumption here is that you're talking about asyncnet though, right? If you want, you can use the `selectors` library in the stdlib to do the calls yourself and h

Tcp buffer reuse for lower memory use

@termer this feature is only available on the Linux kernel and I was not talking about this. I am sorry for not providing detail I want to allocate once and reuse that memory to read and write multiple times. In the initial question, I talked about golang io.CoppyBufer() which will allocate once

Tcp buffer reuse for lower memory use

If it's possible in C then it's possible in Nim. The question is whether you want to go down that low and do it yourself. If you want to interact with kernel buffers, you could try implementing something with io_uring if you're on Linux. Someone's working on a [Nim port of liburing](https://git

Speeding up compile times

Please find some nim bench compiler tool which could help with the topic: Clang is definitely visible faster forvnim compilation, GCC produces faster code sometimes

Speeding up compile times

@vanyle \- I always use [the mob branch](https://repo.or.cz/w/tinycc.git), but virtually never have trouble on Linux x64 with `nim c --cc=tcc --mm=markAndSweep` except that the code runs more slowly in exchange for the faster compile times, much as would be the case for `gcc -O0`. I will reiter

Speeding up compile times

Here the difference is quite noticeable according to the C compiler used. See the Nim devel compiler build time: * **LLVM/CLANG 16.0.1** : 111.20s * **GCC/niXman mingw-builds 12.2.0** : 157.35s * **GCC/winlibs 12.2.0** : 416.66s All cache is deleted before each test run and compilation

How to disable highlighting in nim rstgen

Any update on this? I am kind of confused.

Speeding up compile times

Reading 2 year old posts about IC is kinda depressing. I'd like to help, but I have no idea of what's missing for IC to work.

Nim v2 and gcsafe

Isn't gcsafe going to disappear with arc/orc as refcounting removes the need to have a per thread garbage collector that needs safety?

Nim v2 and gcsafe

It only got "stricter" because lots of bugs have been fixed, previously it wasn't really sound, now it is (to the best of my knowledge).

Nim v2 and gcsafe

I started compiling some of my projects with Nim v2 and I get a lot of errors about gcsafety that I did not have with 1.6. Some nimbles are not gcunsafe, docopt does not compiles any more and nauthy is no longer gcsafe. I was under the impression that gcsafe would be a lot relaxed with arc/orc,

Scan syntax tree for procedure calls

> I stopped parsing the AST and I'm using tag-tracing now, so if someone missed > anything, it was probably you! Ok, fair enough.

Speeding up compile times

> I tried using clang I begin to wonder if I should really miss something? It was my strong feeling, that whenever compile times are more than a few secs, then 90% of the time is consumed by the Nim compiler, and only 10% by C backend? Has that changed? Because Nim compiler is single threaded,

Speeding up compile times

I tried using clang and I'm getting about the same times. tcc does not work with Nim sadly. I'll try using the compiler you provided.

Why sec copied as ref?

Thanks. So it's a legacy behavior that's going to be fixed with nim 2.0.

Why sec copied as ref?

It's an odd feature of `refc` documented somewhere. `seq` and `string` inside a `let` is treated as an alias to the collection.

Why sec copied as ref?

All fine here: variable: 1 field: 1 field in proc: 1 salewski@hx90 /tmp $ nim -v Nim Compiler Version 1.9.3 [Linux: amd64] Run But you may try "var copy = session.inbox", I think there was an issue with let maybe 6 years ago.

Why sec copied as ref?

There are 3 cases, [play](https://play.nim-lang.org/#ix=4thW), in first and secod `seq` copied as `val`, in third as `ref`, why? block: var inbox = @[1] let copy = inbox # val inbox.setlen 0 echo "variable: ", copy.len # => 1 type Session = ref object

State of HTTP Servers in Nim

Multithreaded performance on microasynchttp server is INSANE, it blows Chronos out of the water. I'm getting over 200k requests per second on my desktop, I was only getting about 130k with Chronos. I'll have to do some more testing, but memory seems pretty stable hovering around 40mb when I use

Scan syntax tree for procedure calls

I stopped parsing the AST and I'm using tag-tracing now, so if someone missed anything, it was probably you! In all seriousness, this ought to cover all the cases. If you call the C-API in the indented code block you had it coming. I also just switched to generic types in the `generics` branch

Scan syntax tree for procedure calls

> You know, maybe I ought to go with withTransaction not because it's better or > worse, but to be a contrarian. The world needs more contrarians but I can almost guarantee the AST inspection that you perform is neither complete (what if the call to `commit` is in some helper proc you don't tra

Object Arrays

In general, the more type constraints you put on neural network, the more painful it is to deserialize them when you save/restore the weights. You can't just read the file and figure out the model, you need to the end-user to actual provide the exact types, including in and out from that file.

Speeding up compile times

Thank you very much for your kind explanations. Actually, I generally assume good intents from other people, but as it is obvious that some people don't like me, I have asked Google, pons.com, and dict.leo.org. Google translates it with "Alter", and the other two show "Alter" as well, and some m

Speeding up compile times

@Stefan_Salewski, just FYI for your English learning, "dude" is equivalent to "bro" (friendly) or "random man" (neutral). It's generally considered either neutral or positive and typically used in reference to males, but it can be used to reference females if you want to be funny :P As far as I

Scan syntax tree for procedure calls

Thank you! In @Araq's defense, you can always raise an exception to trigger a reset. And `withTransaction` only responds to compile-time logic. If you have a runtime-conditional write, you always get a commit, as proposed. You know, maybe I ought to go with `withTransaction` not because it's be

Tcp buffer reuse for lower memory use

@mildred nim is fast and small and because of this I wanted to use it in small spaces networking environment where every byte matters but seems like nim doesn't have enough maturity when it comes to networking, I don't understand why reading from tcp returns strings in nim. So is it not possible

noob question exception and await

Hi, Let say I have this code : proc handler(req: Request) {.async.} = if req.url.path == "/hello-world": let msg = %* {"message": "Hello World"} let headers = newHttpHeaders([("Content-Type","application/json")]) await req.respond(Http200, $msg, headers)

Tcp buffer reuse for lower memory use

@sls1005 your example does not work got this error : type mismatch: got

Speeding up compile times

Dude, what are you on about

Speeding up compile times

>From your post, I believe you are using Nim on Windows. If not, disregard. Well, if you're using gcc, especially the winlibs.com distribution, your poor compilation time could be down to that gcc/mingw64 distribution. I currently use the gcc/mingw64 distribution of [niXman mingw-builds-binarie

Scan syntax tree for procedure calls

For what it's worth I prefer your original design. If I'm looking through the documentation `withTransaction` is pretty obvious while `commit` used like that is a bit odd. Besides with Araqs design you no longer have the option to have logic determine whether you commit or not.

Scan syntax tree for procedure calls

> It's pretty bad DSL design. Here is a better one: Thanks! Could you be a tiny bit more specific about what's bad about it, aside of naming?

Speeding up compile times

> And please don't call me dude again, German translation seems to be "Alter", > and when someone calls me that on the street, they may get some serious > trouble. Dude, chill.

Nimforms - A simple GUI library for Windows

@pp, You're welcome.

Scan syntax tree for procedure calls

> What do you think of this design? It's pretty bad DSL design. Here is a better one: import limdb let db = initDatabase("foo") db.commit: t["foo"] = "bar" db.reset: assert t["foo"] == "bar" db.commit: assert "fuz" notin t #

Nimforms - A simple GUI library for Windows

@treeform, createHandle is the function where the actual call to CreateWindowEx is happening. Users can change the default values of any control right before it is created. But yeah, if you think calling createHandle too much time is annoying, I can add a boolean parameter to the constructor. If

Scan syntax tree for procedure calls

> > When I first read about it I steered clear- I was struggling with generics > > and it seemed like >> just another one of Andreas' schemes to make my code > > harder to compile. > > Wait ... what? When you are used to dynamic languages, visible restrictions to enforce safety or keep data fl

Scan syntax tree for procedure calls

This design here is a tiny bit magical but since you can override the magic and be explicit in a natural-feeling way, it might be the best of both worlds. It might also be a horrible nightmare of unclear corner cases. Care to play a guessing game with me? import limdb let

Scan syntax tree for procedure calls

> When I first read about it I steered clear- I was struggling with generics > and it seemed like just another one of Andreas' schemes to make my code > harder to compile. Wait ... what?

Scan syntax tree for procedure calls

That's cool, so I think I'll use it in a 1.0 compatible way, or at least 1.4, since it's a library. I'm surprised how well tag tracking matches this need. I read about it and it seemed neat but I somehow imagined it was going to be overly restrictive. Far from it, it just does what it's suppose

Speeding up compile times

> You could also look at using a caching c compiler like zapcc I have no idea why you gave such advice? For latest version of my SDT tool, Nim compiler takes 42 seconds, and gcc backend 3, so 45 s total. On modern AMD Ryzen 9 5900HX, 8 core, 64 GB. So what may zapcc improve? But well, I may com

Speeding up compile times

If you don't know about it, might help you. Specifically, if you are using `gcc` then `-O0` might help for your "fast iteration" work flow. Or, if you can, `tcc`. (You may need to use an older GC like --mm:markAndSweep to get that to work these days.)

Scan syntax tree for procedure calls

Tag Tracking has been in the manual since at least 1.0, the experimental bits are the StrictEffects, 'effectsOf' and 'forbids' stuff which build on top of machinery that has been a part of Nim since the beginning. So, when used as I've done in my toy example, it's not experimental. In particula

Scan syntax tree for procedure calls

> implement something big and find out what breaks You got the wrong guy! Betting the farm on a niche language? No problem. But stuff labeled 'experimental' is where this programmer draws the line.

Scan syntax tree for procedure calls

> One thing to note about using effects though is that it only tells you that a > write or read might be called Yes, in this case that's fine- if it's an automatic transaction, we commit if there might be a write, but reset if we're sure there was no write. For a read-only transaction we error

Speeding up compile times

You could also look at using a caching c compiler like zapcc

Scan syntax tree for procedure calls

One thing to note about using effects though is that it only tells you that a write or read _might_ be called proc read(): string {.tag: [Read].} proc somethingElse() = # This has the Read tag, but read() is never actually called if 2 + 2 == 5: read()

Speeding up compile times

Incremental Compilation is one of the roadmap in 2023, so hopefully we'll get it soon :)

Nimforms - A simple GUI library for Windows

Really nice!!! Thanks!!!