Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread dom96
> Sorry to be cheeky, but, New Nim users (and programmers in general) need to > learn the difference between concurrency and parallelism. :-P Thank you! I'll be honest and say that I've actually learned this myself when I was writing Nim in Action. This is also why I spend quite a bit of the

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread rayman22201
No, my definition is not exact, but I hope it was good enough to get the point across. Technically, in the most pedantic sense, a "thread" is a unit of execution (a stack, a set of registers, and an instruction pointer). By that technical definition, a "thread" is a unit of concurrency, you

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread Stefan_Salewski
> This is a common confusion. > > Threads: Literally running two different pieces of code in parallel at the > same time, on two physically different CPU cores. Are you sure your definition is exact? I have the feeling that threads often mean concurrency, which is not parallel. See

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread mikra
many thanks for your detailed explanation - so it was my misconception of the "front end compiler trick"

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread rayman22201
> Just for reference, the main thing that I think we need delivered is the > ability to await a FlowVar. You can already poll a FlowVar which allows you > to sort of await it in a poor-man's fashion. await (spawn foo()) should Just > Work (TM) and work in an efficient manner, i.e. the waiting

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread rayman22201
> So the question could be: whats the audience/usecase for async/await - > feature vs threads? new Nim users could be confused about that (like me). > > I don´t think it´s a good idea to "marry" both - but that´s just my humble > 2cts.. Sorry to be cheeky, but, New Nim users (and programmers

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread rayman22201
@Mikra, It's nice to find another Joe Duffy fan. His posts are long, but always super interesting! Actually, Nim's implementation of async is actually _very_ similar to the C# version, which is very similar to the Node version, which is how old Python did it. TLDR; they all read the same

Re: How do I read user input on the same line a string echos

2019-06-20 Thread Nukley
nvm it worked now, something was being stupid idk why.

Re: How do I read user input on the same line a string echos

2019-06-20 Thread nepeckman
Can you be more specific about what didn't work? The code I posted puts the prompt on the same line as the input being read, which seems like what you were asking. Link to hosted version: [https://repl.it/repls/LovingOpulentOffice](https://repl.it/repls/LovingOpulentOffice)

Re: How do I read user input on the same line a string echos

2019-06-20 Thread Nukley
didnt appear to work...

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread mikra
I meant that the async implementation of nodejs compared to the c# ones seems to be different: [https://nodejs.org/en/docs/guides/dont-block-the-event-loop](https://nodejs.org/en/docs/guides/dont-block-the-event-loop)/ and

Re: cannot evaluate at compile time: i

2019-06-20 Thread andrea
The fact is that `entry` is a tuple, hence the type of `entry[i]` depends on `i`: for `i < 5` it is `float`, while for `i == 6` it is `string`. The type checker, to perform its work, must be able to evaulate `i`` at compile time. If, say, ``i` was a constant, what you did would be ok. The

Re: cannot evaluate at compile time: i

2019-06-20 Thread Araq
`tup[i]`'s type would be sometimes `float`, sometimes `string`. Doesn't work. No regression here.

Re: cannot evaluate at compile time: i

2019-06-20 Thread trtt
I thought the same and I remember faintly that I used indexing on nim tuples a few years ago. Maybe this is a regression.

Re: cannot evaluate at compile time: i

2019-06-20 Thread Stromberg
Nims tuples do support indexing. [https://nim-lang.org/docs/tut1.html#advanced-types-tuples](https://nim-lang.org/docs/tut1.html#advanced-types-tuples) I don't know why it can't evaluate i at the compile time though.

Re: cannot evaluate at compile time: i

2019-06-20 Thread trtt
So nim's tuples don't have indexing support(like in most languages having tuples). Then I'll just use a custom type instead.

Re: cannot evaluate at compile time: i

2019-06-20 Thread miran
`entry` is a tuple, use `fields` iterator for iterating over it. Something like this: for entry in data: var rating = 0.0 for x in entry.fields: if typeof(x) is float: rating += getRating(i, x) Run

Re: How do I read user input on the same line a string echos

2019-06-20 Thread nepeckman
`echo` automatically prints line end, you want `write`. write(stdout, "This is the prompt -> ") var input = readLine(stdin) Run

cannot evaluate at compile time: i

2019-06-20 Thread trtt
What's this: proc getRating(columnIx: int, n: float): float = if columnIx > 5: n * 2 else: n / 2 let data = @[ (1.0, 2.0, 3.0, 4.0, 1.0, 2.0, "A"), (2.0, 2.0, 5.0, 4.0, 1.0, 2.0, "B"), ] for entry in data: var rating

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread dom96
> A vocal portion of the community has not bought into newruntime, or is > keeping the GC for other reasons, but everyone has accepted async. This.  Thank you for writing this. I've only skimmed it, but what I've read makes sense in general. Keep in mind that we already have issues for most

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread dom96
> Nim´s one is more like in node.js (I think). If you process large chunks at > once or a endless loop is placed inside you will break your entire system... No idea what you mean here exactly, but it sounds wrong.

How do I read user input on the same line a string echos

2019-06-20 Thread Nukley
I am new to nim so i might sound extremely dumb, and if the title makes no sense I'll try to compare it to something all of us might be familiar with. This batch script does what I cant get a readLine(stdin) to do. set /p input="v Rather than down here, Input goes here->" While in nim it would

Re: [FFI] Reference xxx without definition

2019-06-20 Thread yglukhov
This line looks wrong, should be `--libs`. {.passl: gorge("pkg-config --cflags minizip") .} Run Also `header` pragma is not required for C interop as long as you define the function signatures correctly.

Re: test for nil

2019-06-20 Thread MerryMurray
Solved. Great. Works. Thank you. Just starting nim. Enjoying myself.

[FFI] Reference xxx without definition

2019-06-20 Thread mantielero
I am playing with nim FFI (newbie speaking). I am trying to wrap [minizip](https://github.com/madler/zlib/tree/master/contrib/minizip) for the sake of learning a bit. I have minizip installed under ArchLinux. What I have so far is: #proc fmi_zip_unzip*(zip_file_path: cstring;

Re: psuedo RFC for async Channels and FlowVars

2019-06-20 Thread Araq
@rayman22201 Well yes. What you write makes sense. Now we "only" need to write the code... :-)

Re: Best way to represent AST

2019-06-20 Thread mratsim
The idiomatic way is with ADT (object variants) like Araq showed, you will find alternative representations in [this repo](https://github.com/mratsim/compute-graph-optim) where I'm writing a ML compiler, note that I'm trying to get a flexible user-extensible representation so idiomatic

Re: test for nil

2019-06-20 Thread leorize
Yea, that part is rather misleading, but it's due to how `docopt` [convert that to string](https://github.com/docopt/docopt.nim/blob/65da8739a7534b8d78249a90778e1b38d4bdcf5c/src/docopt/value.nim#L82). Looks the the correct way to check for that is: if args["--wid"].kind == vkNone