You can use a {.experimental: "ForLoopMacros".} to rewrite the for loop.
See for example the impelmentation of Python enumerate
import macros
{.experimental: "forLoopMacros".}
macro enumerate*(x: ForLoopStmt): untyped =
expectKind x, nnkForStmt
# we strip
try
echo treeRepr nimNode
Run
Hello everyone, I would need to debug the NimNodes returned from
getImpl
Run
calls, and I was looking for a function that would print out a NimNode tree
structure given a NimNode, not a block of nim code. I looked at
dumpTree
Run
, but
Well ... I'm sure it doesn't help much, but I agree with both @dom96 and
@cheatfate. Since I'm still on holidays, please expect a longer answer here
later.
`for c in Color.low..Color.high` produces enums, its what the `for c in Color`
iterator does.
Anyway, its pretty easy. The enum values are scoped. With some more state
keeping and macro sugar you can even define and use anon enums as function
params.
import
macros
The above example seems to be exactly the desired solution, thank you all for
your proposals.
Issues from this list if async issue which you still ignoring, but still
important:
1.
[https://github.com/nim-lang/Nim/issues/3590](https://github.com/nim-lang/Nim/issues/3590)
"asyncnet.recv hangs when the socket is closed"
2.
Also i want to remember about very important part of asyncdispatch -
selectors.nim, and your work with this part. Do you remember
No using QQ for long. Maybe try WeChat if you got a WeChat group for Nim.
I would like that strings can be assigned directly to seq[uint8], as a cstring
generally is a valid uint8 sequence.
Something like
var s: seq[uint8]
s = seq[uint8]("Text data for proc with uint8 based parameters".cstring)
Run
The actual fact is, that we have some
`converter toSeqUint8(s: string): seq[uint8] = cast[seq[uint8]](s) let s:
seq[uint8] = "test" doAssert s == @[116'u8, 101, 115, 116] `
Run
>From a type-safety point of view, I think such a conversion should not be the
>default, while `string`, `seq[byte]`, `seq[uint8]` and `Taintedstring` are all
>equivalent at a low-level, they should represented completely different
>semantics.
Implicit conversion should be left at the library
OK, so a cast does indeed work, and lenientops may also support it (will visit
that module soon) but a plain safe type conversion does not work? Strange -- is
that just because no one had the time to implement the type conversion yet?
A cast is too unsafe of course, no one can guarantee that
Nim is not backed by a large company, the devs efford is already very high.
Just go ahead and collaborate. I've translated many open source websites to
Spanish.
I'm sure if any of you provide the Chinese translation of nim-lang.org the team
will be very happy to public it.
Of course it completely depends on the IT field you work on. I have experience
working with mastodon apps in big teams with teams of more than 20 developers.
In that kind of scenario the performance is the smallest problem you will have
to handle.
And of course the performance is very
> I've translated many open source websites to Spanish.
How do you manage to keep them up to date?
I have not even managed that for my own homepage -- started that page 20 years
ago in english/german, and keep both in sync in the first years. But later I
updated only the english content, and
what I meant by lenientops is that it's better to have strong default in
system.nim and that extra libraries like lenientops would be better to
introduce unsafe auto-conversion between types.
To be clear, lenientops only does conversions for numerical operators at the
moment. The safe
Sometimes I have loops like
for state in 0 .. 1:
if state == 0:
Run
It would be better iterating over enums, like
type
Color = enum
red, green, blue
for c in Color:
echo c
if c == red:
No, will not try that, as that is iterating over integers, and I would have to
define the enums in a type section before. Not really my intension.
try
c in Color.low..Color.high: echo c
Run
20 matches
Mail list logo
