That's what I said. ;-)
@Araq: and all...
Since no one else seems to have filed an issue on this, I just did as
[issue#12116](https://github.com/nim-lang/Nim/issues/12116). I further refined
the problem as it has nothing to do with having global variables or seq's, but
only to do with passing an owned ref to a sink pr
Water Dispenser Tap & Faucet(KOKOELECTRIC)
[https://www.kokoelectric.com/product/water-dispenser-tap-faucet](https://www.kokoelectric.com/product/water-dispenser-tap-faucet)/
are indispensable commodities in modern society. Although they are only
small faucets, we should pay attention to main
I guess you're right that it would need a change to the compiler but AFAICT
'proc' fields of an object are in the same situation and we have an iterator
(more precisely an unrolled for-loop) for field name/type pairs.
For ASTs use a Nim "case object". Nothing else works as well.
I don't think it's possible and even if it were, you couldn't invoke the procs
since their parameter types would vary quite a bit.
> Is there a way to statically reflect on proc's in scope that accept some
> object as their first argument? For example, I'd like to do something like:
# module M1:
type
O = object
proc p1(o:O) = discard
proc p2(o:O) = discard
# module M2
import M
Do you mean to create the AST? Well I did look into it but it is a huge
dependency, especially on Windows and Linux.
tree-sitter allows for a really light dependency that can be easily deployed
cross-platform. Further, I am only looking at creating wrappers, not conversion
of implementation out
Thanks for the response! Though I do not try to use dynamic dispatch for
iterators, am I wrong? I directly check runtime type inside of the iterator, so
it is always using the only iterator version , `Ast` one, isn't it?
Anyway, I found my original problem. It was because type `D` can only hold
An illustration.
type
A = ref object of RootObj
B = ref object of A
method m(v: A) {.base.} = echo "mA"
method m(v: B) = echo "mB"
proc p(v: A) = echo "pA"
proc p(v: B) = echo "pB"
iterator items(v: A): string = yield "iA"
iterator items(v: B): stri
But you may workaround this by having separate iterators for types:
# continuing the previous example
method mi(v: A) {.base.} =
for i in v: echo "mi A, " & i # ``iterator items(v: A)`` is called
method mi(v: B) =
for i in v: echo "mi B, " & i # ``iterator items(v:
Because `iterator` is a kind of `proc`, not a kind of `method`? So, no dynamic
dispatch for it, and its argument (`ast: Ast`) is always of statically stated
type, i.e. `Ast`.
Hello everyone, so I'm trying to make a simple C compiler in Nim. I needed to
change AST node types, so I wrote something like this:
type
Ast = ref object of RootObj
A = ref object of Ast
B = ref object of Ast
B1 = ref object of B
B2 = ref object of B
You can also use `echo repr(variable)` to print out a basic representation of a
variable.
Use your editor's "nimsuggest" integration.
> new Nim compiler version produces different nimcache sources from the same
> .nim sources, so which ones are the "real" ones now?
This is a feature rather than a problem. The .nim files are the "real" sources
and the .c files are artifacts. If you commit the .c sources you can then
inspect ho
Thanks Stefan I have bookmarked them will work thru those too. What I was
hoping of doing is focusing on Python and then slowly on the side work thru
Nim's book and tutorials.
or
download from https://ftp.pcre.org/pub/pcre/pcre-8.43.tar.bz2
./configure --prefix=/usr \
--docdir=/usr/share/doc/pcre-8.43 \
--enable-unicode-properties \
--enable-pcre16 \
This is all very instructive; thanks a lot. I'm wondering if you have
benchmarked your nim codes with, say, C/C++ alternatives (or even a simplified
C++ code you wrote yourself). Dealing with GC is something new to me; I'm
concerned how this would impact numerical simulations, for example, if
d
19 matches
Mail list logo
