@Udiknedormin don't object variant use fat pointer anyway?
In any case, I tried version 2 and it makes lots of errors very hard to check.
See [issue #6331](https://github.com/nim-lang/Nim/issues/6331)
In this code the type signature should be
template shape*[B,T](t: Tensor[B,T])
try returning after server.close
Edit: also this is this bug
[https://github.com/nim-lang/Nim/issues/6186](https://github.com/nim-lang/Nim/issues/6186)
Edit2: do you set killServer = true in your code?
To store defferent types values in one seq with no (when values are of the same
size) or minimal memory overhead, and no CPU overhead, one has to use casts
(`cast[]()`), obviously at the coast of non-distinguishing their types; that
is, it just has to be known, at what index what type is used,
Actually, it can be possible to use both variants of Node2 in one seq by using
concepts (not to mention converters). However, it will always use fat pointers
which makes it a lot slower, especially if we compare it to seq[NodeObj]
instead of seq[Node].
[https://github.com/Yardanico/nimpylib](https://github.com/Yardanico/nimpylib)
well, if you're objective is to try and appeal to the Python community, I think
they might wonder what's the benefit of using Nim rather than,say, Cython,
which maps more closely to "real" Python
Also this (changes type at runtime):
type
NodeKind = enum
nkInt, nkFloat
Node = ref NodeObj
NodeObj = object
case kind: NodeKind
of nkInt: intVal: int
of nkFloat: floatVal: float
let a: Node = Node(kind: nkInt,
Yes, Stefan_Salewski is right:
type
NodeKind = enum # the different node types
nkInt, # a leaf with an integer value
nkFloat# a leaf with a float value
# Version 1 with object variant
Node = ref NodeObj
NodeObj
You can store variables of type Node all in one single seq.
For node2: I really think that there is no way to store variables of type
Node2[nkInt] and Node2[nkFloat] in the same seq.
So Node 1 is more dynamic. But I am not really sure, have never used object
variants...
Thanks. Magnificent hack, seems to work as expected.
Just a random brainfart.
Would probably start by taking typeshed static type declarations for python
builtins.
String would probably be a wrapped unicode/runes string; bytes would be mainly
native c bytes.
Arbitrary precision int libgmp.
There's already a lot of libs which bring python-like
Check out this
[hack](https://play.nim-lang.org/?gist=cc87d451c7338247e4daf475cde2ca1b):
template testScope =
template ret = return
when compiles(ret()): echo "Function"
else: echo "Wild West"
proc test = testScope()
test()
@Udiknedormin: you can use bleeding edge devel branch(0.17.1) on github to test
this newly fixed object contruction syntax. or wait until next version released
Is this description of methods correct?:
Methods are called using the "dynamic type" of the parameters, while procs use
the "static type".
It now compiles successfully, but it doesn't seem to be killing the server when
I trip that killServer block. It will run over the line and continue on with
execution.
Hi,
I have an exported template which is logically should be called only as a top
level statement in other modules. If it is incidentally called inside a proc it
breaks thread safety (template changes global var). And this is multithreaded
application, nim code is single threaded but wrapping
16 matches
Mail list logo