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

I hope this gets the point accross. type Mat = object a: array[10, array[20, int]] proc apply(m: var Mat; op: proc (x: var int)) = # callback style for i in 0..<10: for j in 0..<20: op(m.a[i][j]) var m: Mat apply m

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

Exactly. Each function is not a duplicate exactly, just mostly, it's tailor made for it's use case.

Output AST in a recursion, using an output parameter or returning, which to prefer?

i think passing a bool would work

Output AST in a recursion, using an output parameter or returning, which to prefer?

Usually when writing macros, I code the helper procs that traverse the AST returning `NimNode`, as I find returning easier to reason with: proc x(n: NimNode): NimNode = case n.kind of nnkIdent: result = newStmtList(ident(n.strVal)) else: result = cop

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

Oh, got it. So you want to move the runtime decision out of the loop, at the cost of having a lot of duplicate code in the resulting binary.

std/asynchttpserver or httpbeast

httpbeast is written to be as fast as possible (thus uses threads) and supports only Linux/Mac. asynchttpserver is a simple implementation which does not support threads and thus doesn't perform as well as httpbeast. Supports all platforms though. If you're unsure just use asynchttpserver, it's

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

"doesn't give you any benefit" \- well it does. It gives me 10-30% speed up. Why? I moved the runtime branches out of a for loop. Instead of doing a run time branch per pixel a ~million times I do it a run time per image times ~10 times. It is much faster this way. But how can I make the code lo

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

Sorry, I don't understand what you mean. Even if I send blendMode as a template I still need to switch on the templates? And the Booleans of inPlace and Smooth. Do you have a link to your similar code?

recursive iterators - is there a recommend workaround?

Having to toss a `toItr` macro wrapper on closure iterators is really not so awful. BTW, you should probably use @slonik_az's more general `toItr()` of that thread I linked to.

Set base address of sequence

I saw in some libraries and used the following technique to interop with C code. For example // sum.c long long sum(long long* xs, unsigned int len){ long long s = 0; for(int i=0; i

recursive iterators - is there a recommend workaround?

Sorry, I don't get the argument. I am not against inlining iterators. But I do want the compiler to select an optimal (but correct) implementation. And for simple iterators (= current iterators) I'm sure the compiler is able to find out

recursive iterators - is there a recommend workaround?

Nim "efficiency, expressiveness, and elegance (in that order of priority)." So from that perspective the hard separation into inline and closure iterators makes a lot of sense, as closure iterators are a lot more heavier than inline iterators, it's opt-in.

recursive iterators - is there a recommend workaround?

Thanks for the pointer. >From a programmer's point of view: Generators (iterators) and recursion are >central features of all modern programming languages. They should not be >limited unnecessarily. Generators/iterators should have all benefits of a normal procedure (i.e. allow for forward dec

Strange error message from collections/sets.nim

> Indentation's purpose is to show scope, I'm uncertain if alignment even makes > more readable code. No, indentation is certainly not a way to indicate scoping as in old languages, such as Pascal, an IF, a FOR or a WHILE statement doesn’t create a new scope. Even in Python an if, a for or a wh

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

Make your `drawUberStatic` a template that takes `blendMode` as a template. Think of it as taking a callback but thanks to the templates, the compiler is enforced to inline it. Might take some time to grasp but it should work, I wrote similar code.

Eminim - JSON deserialization macro for Nim

Hello all, I would like to present you It provides a `jsonTo` proc which deserializes the specified type from a `Stream`. It generates code, in compile time, to use directly the JsonParser, without creating intermediate `JsonNode`. **Limitations** * Lim

std/asynchttpserver or httpbeast

If you decide to use `std/asynchttpserver` please use the new API (Nim devel, or one of the upcoming releases).