many thanks, it works! (I'll try to search and read about static types)
Looks like a bug, type pragmas are not seen on the user side
type
User {.exportc, packed.} = object
id: int
import macros
macro test(t: typedesc): untyped =
echo t.getType()[1].symbol.getImpl.treerepr
test(User)
gives
add static to the type
import macros
macro initNui(a: static[int]): typed =
result = parseStmt("const b = " & $a)
initNui 1
see also
[https://github.com/PMunch/protobuf-nim](https://github.com/PMunch/protobuf-nim)
(doesn't rely on protoc compiler; cf
[https://github.com/oswjk/protobuf-nim/issues/2](https://github.com/oswjk/protobuf-nim/issues/2))
+ a discussion of related packages here:
[https://github.com/PMunch/p
Hello. I tried to represent int to string inside a macros:
import macros
macro initNui(a:int): typed =
result = parseStmt("const b=" & $a)
initNui(1)
but I had compilcation error:
unhandled exception: false Invalid node kind nnkIntLit for
Very nice! I tried to go a different route and make the entire parser in Nim as
well. The result is being able to only call the macro with the name of your
protobuf specification file and have Nim do the rest. This means that you don't
even need the protoc compiler to use protobuf in Nim! I know
@twetzel59 - I use fork (and even vfork) all the time. They work just fine.
@Krux02 - I have never used compiler-as-a-service mode which seems originally
targeted at IDEs, but that feature may apply to testing as well. See
`compiler/service.nim` and `tests/testament/caasdriver.nim`..maybe search
well, I'm found [similar theme](https://forum.nim-lang.org/t/3061/2). This
works:
import macros
macro load*(modulesSeq: varargs[untyped]): untyped =
result = newStmtList()
for module in modulesSeq:
result.add parseStmt("from " & $module & " import nil")
Not having worked on the compiler, I can't guarantee anything, but here would
be my first 3 questions:
* Has anyone successfully used `fork()` from Nim?
* Does this memmapping mess up the GC?
* What about handling dead processes? Before too many tests are executed the
compiler would need t
Cool! I ran it and got similar results.
Hi. Does Nim supports anything like a "dynamic packges loading"? For example, I
have 3 packages:
pack0.nim (root package) contains:
var dstBack = 0 # some variable-indetifier (will indicate, from wich
poackage someProc will be called)
macro init*(back:int) = # so
It's a post from 2013 .
Anyway the idiomatic way to do scope guard is with a template that does try:
body finally: as it's done by Udiknedormin
[here](https://forum.nim-lang.org/t/3205/1#20223).
There is an example in the [guards and lock
section](https://nim-lang.org/docs/manual.html#guards-a
If performance is your concern, use Nim methods.
I benchmarked them vs procs and closures and I found out that they are only 3
times slower than regular proc:
[Bench](https://github.com/mratsim/Arraymancer/blob/master/benchmarks/implementation/proc_method_closure_bench.nim).
Don't run it on the
Thanks for clarification regarding Nim! (but, as I know, "reflection" is a
conception relating only for runtime. everything else is something different)
In the following code, with the error line marked with a "119", I get a
SIGSEGV. Software distribution is arch linux on this machine.
var envs, wavs, fms, macros: seq[tuple[name: string, values: string]]
var name, artist: string = ""
var tickrate: int16 = 0
...
I think maybe this is template bug. These code doesn't compile from @zielmicha.
template bar() {.dirty.} =
echo a
template foo() =
let a = 5
bar()
foo()
But when we turn foo into proc, the code works.
template bar() {.dirt
Is there a way to check an object type for a custom pragma?
In the manual there's an example of a custom annotation on a type, but it isn't
([https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-custom-annotations](https://nim-lang.org/docs/manual.html#implementation-specific-pra
Araq, should I be avoiding the use of `method`? I generally consider it useful,
especially as it allows dynamic dispatch through dispatch trees as opposed to
function pointers. Due to performance concerns, I am often (unreasonably?)
averse to function pointers.
* * *
Here's my two cents:
I ba
@Dennis my bad I should've verified the D code I posted; with tuples though we
have:
import std.stdio:writeln;
void fun(T...)(T n)
{
static foreach (x; n)
writeln(x);
writeln("L=", T.length);
}
void main(){
import std.typecons:tuple
19 matches
Mail list logo
