"for i in 1 ..2:" give syntax error while "for i in 1..2 or 1 .. 2:" works.
also x = x -10 gives syntax error. x = x-10 and x = x - 10 works fine.
Normally, I am consistent with spaces or no spaces so this isn't a problem for
me but the error message resulting from accidentally leaving out the
A long time ago I suggested that to attract new developers a mailing list would
be ideal. Following the forum is just inconvenient for me. My email client is
vastly superior than any forum or rss interface. I find discourse much worse in
term of user interface than nim-forum (at least this
[Related thread.](https://forum.nim-lang.org/t/3534)
I hope the Nim ecosystem comes up with it's own alternatives - eventually even
to GitHub, Linux, and the browser stack.
the codes is blow:
type entry = tuple
id: uint16
qname: string
qtype: uint16
var obj: entry
obj.id = 1
obj.qname = "this is demo"
obj.qtype = 21
var socket = newSocket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
discard
I can see Nim:
[https://hacklines.com/en?tags=Nim](https://hacklines.com/en?tags=Nim)
The Nim Forum is a staple of Nim. I'd rather spend time improving it than
switching to Discourse, are there features of Discourse that you think might
make it more accessible?
There are also other places to
> No. I couldn't get people to test this feature, sorry.
You should have advertised it more. I didn't even know this feature existed...
> Has anyone successfully used these on something non-trivial?
No. I couldn't get people to test this feature, sorry.
> I often get request for RTTI generation for incomplete object errors on
> things that should work
Well, the compiler begs to differ. Not sure how much these can be mitigated
@mratsim: That sounds quite similar to what I made, except with classic vtables
of proc pointers, while mine contain field offsets. Is there any chance that
similar functionality could be supported by this vtref feature? The compiler
could additionally generate getters and setters and add them
@StasB, the future VTable and vtptr and vtref are hidden
[here](https://github.com/nim-lang/Nim/blob/c671356d51488c96b4749a4d109b00d924e1f739/doc/manual/generics.txt#L585-L639).
Thx for the help. One more question : is there any way to forward declare a
variable without knowing the exact type?
if flag == true:
var c = 5
else:
var c = 10.0
The if statements here open a new scope so I no longer have access to the c
variable. I was
use `when` , as long the variable can be know at compile time
import typetraits
const flag = true
when flag == true:
var c = 5
else:
var c = 10.0
echo name(type(c))
take a note that's only for compile time, you cannot switch during runtime
`nimsuggest` doesn't help?
I think what it boils down to is that syntactic flexibility and good error
messages are at odds, simply because the parser can keep going quite a long way
past the point where it's already clear from the context that the result will
be semantically invalid, as long as the code happens to be
To drive my point home, I shall now reveal what the compiler tells the errors
are. And boy, they are bogus.
type MyTuple = tuple(a: int, b: int)
# syntax...Error: invalid indentation
var myTuple: MyTuple = [a: 10, b: 10]
# syntax...Error: invalid indentation
Having access to various Ruby article feeder sites I recently came across this
[https://hacklines.com](https://hacklines.com)/
[https://hacklines.com/en?ucc=rubyflow=Ruby%2CRails%2CSinatra](https://hacklines.com/en?ucc=rubyflow=Ruby%2CRails%2CSinatra)
which is multilingual. It lists articles
> vtref is virtual table ref.
I think what I did is already a virtual table ref of sorts, so I'm not sure
what boia01 meant. Maybe that something like this (or better) is already being
planned for the Nim core? That's always preferable to improvised solutions, I
guess.
> what's the advantage
While `StoreKind` can be any of `StoreInt|StoreFloat|StoreString`, once it is
instantiated, it will stay that one. Instead you have two choices:
1\. derive from a common `Store` object:
type
Store = ref object of RootObj
dep: seq[Store]
req: seq[Store]
Well, you could do this:
type
StoreInt = ref object of RootObj
val: int
dep : seq[StoreVariable]
req : seq[StoreVariable]
StoreFloat = ref object of RootObj
val : float
dep : seq[StoreVariable]
req :
Do you perhaps want it like this?
type
Store[T] = ref object of RootObj
val: T
dep: seq[Store[T]]
StoreInt = Store[int]
converter toInt[T: int](x: Store[T]): T = x.val
var a = StoreInt(val: 5, dep: @[])
echo a.toInt
Thanks! What's a vtref, though?
vtref is virtual table ref.
I don't know much about C++, what's the advantage of virtual table?
type
StoreInt = ref object of RootObj
val: int
dep : seq[StoreKind]
req : seq[StoreKind]
StoreFloat = ref object of RootObj
val : float
dep : seq[StoreKind]
req : seq[StoreKind]
StoreString = ref object of RootObj
val :
These seems like a nice solution to the cyclic type problem, but I've been run
into lots of weird errors.
Here's a simple one that causes a gcc error:
main.nim:
type
plotest.MyObj = object
import defs
proc foo() =
discard MyRef()
Very cool!
(Still ... can't wait for concepts + vtrefs! )
> Quiz 2: Now, imagine that you are a nim newbie. Try to fix the errors with
> the help of nim manual and compiler error messages. Or,better yet, ask a nim
> beginner to fix the code and watch the frustration grow.
Or better yet, you ask a beginner who can read a tutorial again to look at some
25 matches
Mail list logo
