If I add \--tlsEmulation:off, it works again. I'm don't understand what I'm
doing with that though.
I think that issue #1 is a bug if
[https://github.com/nim-lang/Nim/blob/devel/tests/method/tgeneric_methods.nim](https://github.com/nim-lang/Nim/blob/devel/tests/method/tgeneric_methods.nim)
is intended to continue to work.
Good idea. [Here's my attempt at
this](https://gist.github.com/anonymous/e0a225a0fb8f0574ff82aaf51266a091)
Does seem to reproduce the same issue:
$ nim c -r repro.nim
Will it work?
It worked!
$ nim c -r --threads:on repro.nim
Will it work?
Well your solution does work I think. It feels a bit like what Scala is doing
in their collection library. But on the other hand Scala is on the JVM and the
JVM is as badass that it can incline virtual methods. I think in the real world
it really is a lot of overhead, that you do not want in you
I believe what you are running into is this terminal driver issue:
> [http://unix.stackexchange.com/questions/131105/how-to-read-over-4k-input-without-new-lines-on-a-terminal](http://unix.stackexchange.com/questions/131105/how-to-read-over-4k-input-without-new-lines-on-a-terminal)
I finally found some time to work on something I wanted to start immediately
when I discovered Nim: A data frame API allowing lazy out-of-core data
analytics. You can find a first working prototype over at GitHub (under the
uninspired name [NimData](https://github.com/bluenote10/NimData)). So fa
Maybe not the most helpful comment, but I can confirm that this works without
problems on Linux. I only have to increase the buffer size to avoid underruns
-- but has nothing to do with threads:on. In a more complex scenario, it's
important to call `system.setupForeignGc()` at the top of the cal
I wasn't aware of this kind of limitation with standard input. Perhaps you can
find some clues about how to fix this by having a look at the source code of
[pv](http://www.ivarch.com/programs/pv.shtml). I often use it to process data
read through stdin, and I have never encountered problems with
