I do recommend to use the GLvectorf3 type from the OpenGL. There is nothing
inherently wrong with that type, but there is also almost no benefit in using
it, because it's just an alias for an array. There are not typica vector
operations like dot product or cross product defined. I recommend to
@jangko what do you mean with simulated inheritance? In Go you can have an
[embedded type in a struct](https://golang.org/ref/spec#Struct_types). That
means your struct has all methods, that the embedded type also has. This is
effectively pretty much like multiple inheritance. So what simulated
surprisingly, this Go like interface is very similar with what I have
implemented when creating high level wrapper for Chromium Embedded Framework in
[nimCEF](https://github.com/jangko/nimCEF).
in my experience, Nim macro not only capable simulate Go like interface, but
also interface + simulat
+1 to what Krux02 said. If you use Nim like that you don't gain very much over
Python. It will not be faster (as Nim and Python both need the work to be done
at runtime) and you won't avoid errors and lose easier reasoning and
refactoring possibilities because the compiler can't check the types
Ok, I get the problem here. At first I thought you would need an interface
object to interact with languages like Python, where you do not know the
fields. But you what you actually want is to treat Nim like as if it is Python,
and all I can tell you that is a bad idea, and don't do that. You sh
@flyx I guess it's not NEEDED because I can just store it in a table but after
using Python year after year it just seems like something natural.
The "solution" based on posts above is:
import tables
template `.?`*[T](a: T, f: untyped): untyped =
a[astToStr(f)]
@dom68 @OderWat The use case is pretty simple: I just need to upload a docx
file to Google Drive from a CLI tool. The tool was originally written in Python
with PyDrive, so the whole API interaction layer was hidden.
I also thought about keeping the server running the whole time, but this looks
I would like to use [MonetDB](https://www.monetdb.org) in production as our use
case is heavily depending on mysql / mariadb just because it's MyISAM tables
are so fast. PostgreSQL and a lot of other DBs I tried faint already on
importing the data and are magnitudes slower in querying them. But
I thought the same @dom96 but I did not post it because obviously a running
server is one attack vector more in a system if you otherwise can be "closed".
My [Hubic2SwiftGate](https://github.com/oderwat/hubic2swiftgate) is a program
which does something similar:
The the whole server is used to
This is not possible by design.
type
test* = object
Here, you declare an object that has no fields.
var t = test()
Here, you instantiate this object. `t` has the type `test`.
var t.name = "kek"
The compiler now looks at `t`'s type an
What sort of application are you planning to use this in?
I have a feeling that it would make more sense to simply keep the server
running instead of shutting it down and restarting it for each request.
@bpr I never said that monomorphization is a harmful language feature. I just
say that someone needs to be aware of it, and that in some contexts this
monoporphization is in fact a bad thing.
But in c++ it actually is harmful, because the way c++ deals with templates is,
to create all required
With an extra indirection, the following code compiles and runs fine
type
G[N:static[int]] = object
v: int
A = G[1]
B = G[2]
type
F[U] = object
v: U
X = F[A]
Y = F[B]
static:
echo(A is B)
echo(X is Y)
proc p(
I'm having trouble upgrading my old code that worked under v0.13. The following
snippet no longer works under v0.14.2.
type
G[N:static[int]] = object
v: int
A = G[1]
B = G[2]
static:
echo(A is B)
proc p(x:A) = echo "A:",x.v
proc p(x:B) = e
14 matches
Mail list logo
