I understand that. I just don't understand why calling getTypeImpl on a type
gives you a different tree from the one that getImpl on a symbol returns. I
would've thought that the latter would simply delegate the job to the former
when the symbol is associated with a type. Is there some semantic
I solved this by using "\--passL" instead of "\--passC "
In your example t is not a symbol, it is a type. These are two difference
concepts. There is relation between the two, but not 1-to-1.
Wow, fixed already! You're so helpful, that's great!
I see. My initial attempt looked something like this:
proc test(t: typedesc) {.compileTime.} =
echo t.getTypeImpl.treeRepr
static:
test(MyObj)
This did give me field names and types, but no pragmas. It seems like the
pragma information isn't attached d
You need to use latest Nim dev version to compile my example.
You got it almost correct. Nim has a notion of Symbol. Symbols (procs,
typedefs, variables and etc) have many attributes like scope, type and others.
Most importantly, symbols have implementations that you can access using
getImpl pr
I've just had my first look at the logging module. The "Warning" immediatly
caught my eye: "The global list of handlers is a thread var, this means that
the handlers must be re-added in each thread."
If I'm writing a "library" meant to be used by others (eventually), that create
it's own thread
Ok, thank you!
I'm trying to write a (very) primitive "service discovery" module, and it seems
"nativesockets.Hostent.addrList" is not what I would have expected.
Here the code I used:
import nativesockets
import net
import strutils
proc parseURL(hostport: string): tuple[ip: strin
I'm not sure I understand. So NimNodes of the nnkSym kind contain NimSyms that
can be extracted with the symbol proc, and the NimSyms contain more NimNodes?
Your example doesn't seem to compile.
Feature is relatively new, here is an example
import macros
template mykey(s: string{lit}) {.pragma.}
type
MyObj = object
a1 {.mykey("a").} : int
macro my(t: typedesc): untyped =
echo t.getTypeInst[1].symbol.getImpl.treeRepr
my(M
Hi! I've noticed that it's possible to annotate the fields of an object type
with custom pragmas, and that the treeRepr output for the type statement will
reflects it. However, the structure returned by getTypeImpl etc. doesn't seem
to contain anything about pragmas, custom or otherwise. Is ther
I bet a million lines of Nim code was written before this bug was detected,
don't worry.
13 matches
Mail list logo
