Re: nimkernel extended

2019-04-27 Thread mikra
Ok thanks for your feedback. Your template is indeed a very good starter. For me it was an experiment to explore some environmental limitations. I thought about your concerns. I think to avoid confusion I would like to move my fork into an own project with a disclaimer to your original work if y

Re: Nim vs D

2019-04-27 Thread Libman
> why "Projects like Nim and D can never be failures"? I've explained that point. At very least they brought value to the thousands of programmers that used them, but that's just one aspect of their achievement. D (since 2001) and Nim popularized the idea that a language can come close to the e

Re: nimkernel extended

2019-04-27 Thread dom96
Nice! The aim of nimkernel is to provide a simple base for people who want to build a kernel, I think all these things you've added are going a bit beyond that. It's much easier for newbies to understand something like what nimkernel is now than all these extra bits which they might not be awar

nimkernel extended

2019-04-27 Thread mikra
Hi all, I recently extended Dominik's nimkernel a little bit. Some addons are gdt/idt-init, keyboard and PIT. Also qemu's debug-console is spawned and can be used. I used it as a testbed for the 'os:standalone' flag and for some lowlevel experiments with nim and qemu. forked repo is here: [ht

Re: Can I avoid covariance of typedesc arguments?

2019-04-27 Thread bluenote
I'm stupid, I totally forgot that there is the `T is A and A is T` trick that allows for exact type equality comparison. I still think it is a pity that the corresponding PR has been declined ([https://github.com/nim-lang/Nim/pull/8612)](https://github.com/nim-lang/Nim/pull/8612\)). @Stefan_Sal

Re: Can I avoid covariance of typedesc arguments?

2019-04-27 Thread Stefan_Salewski
I wonder why you use at all B = object of A Run when you do not want to enable passing B where A is expected. But it is easy to enforce a compile time error, add proc f(T: typedesc[B]) {.error.} Run

Re: Can I avoid covariance of typedesc arguments?

2019-04-27 Thread mratsim
B inherits from A so B is always A, especially so at compile-time. Maybe methods can help but I'm pretty sure you will be venturing alone in a hostile world with methods and typedesc arguments.

Can I avoid covariance of typedesc arguments?

2019-04-27 Thread bluenote
Apparently typedesc arguments are covariant. For example: import typetraits type A = object of RootObj B = object of A proc f(T: typedesc[A]) = echo "should only accept A, but not B" echo "T is A: ", T is A echo "name(T): ", name(T)

Re: typed and untyped

2019-04-27 Thread bluenote
On input/argument side, the semantics are clear: * `untyped` passes in the raw AST without semchecking (no type information available) * `typed` performs symbol lookup before passing the argument (type information available) On output side, I'm also confused. I usually only use `untyped`