Introducing an async library inspired by Go in Nim

@elcritch Thanks a lot ! Yes I think fewer allocations would be made than async, but the allocations are more costly for stackful, so I don't know if there could be a performance gain. The dispatcher/event loop is the main source of CPU cost, so I don't think one will be largely faster than the

Introducing an async library inspired by Go in Nim

> Well Golang's runtime use cooperative scheduling and folks use it for > parallelism No, the parallelism comes from the `go` keyword and the parallelism comes from Go's runtime using OS threads which don't use cooperative scheduling.

Introducing an async library inspired by Go in Nim

Nice project @Alogani! One thing that always seemed better about stackful coroutines vs async futures would be much fewer allocations. Every async call that has any state incurs allocation overhead. Perhaps also easier to make debugging nicer. Debugging async-futures is annoying in gdb as every

Introducing an async library inspired by Go in Nim

> Well you can have both in the same program but I have never seen a > cooperative scheduling system to produce parallelism. Well Golang's runtime use cooperative scheduling and folks use it for parallelism, AFAICT. Whether that's a good idea or not, who knows.

Stock address instead of plain object in a table : C to Nim

It seems like we're misunderstanding each other. Your objects being a `ref object` is exactly what you want, and the code I shared should do exactly the thing you're after. If I understand you correctly. But lets walk through this. You have 1 objects which are not trivially small (say somew

Stock address instead of plain object in a table : C to Nim

Hello, The rule of thumb is too never confuse and avoid mixing: * untraced pointers (ptr T) * traced pointers (ref T) * stack objects If you want to store the address of a stack object, you are screwed immediatly when the function where your object is defined returns. So you have to cop

Stock address instead of plain object in a table : C to Nim

Well if every object is different how exactly do you think you can save memory?

Natures Garden CBD ➤ Lisäravinteet muistiin ja keskittymiseen: Suosituimmat valintamme?

Natures Garden CBD -kapseleiden sanotaan lisäävän miesten tehoa ja saavan seksielämän takaisin raiteilleen luonnollisten ainesosien avulla. Säännöllisen nauttimisen sanotaan myös laajentavan penistä. Paljon lupauksia suhteellisen tuntemattomasta tuotteesta. Siksi päätimme kokeilla kapseleita its

Smart Hemp Gummies Canada

https://www.facebook.com/Official.Smart.Hemp.Gummies.Canada/

https://www.facebook.com/Official.Smart.Hemp.Gummies.Canada/

Smart Hemp Gummies Canada , the legal status of CBD changes by country and state, so it is fundamental to really investigate close by rules preceding purchasing or consuming CBD things. Shrewd Hemp Chewy candies Canada Ta

Stock address instead of plain object in a table : C to Nim

If your object is already a `ref`, feel free to alias it as you need: var testTable: Table[string, MyObj] proc populateTable() = let sharedObj = MyObj(age: 42) testTable["key1"] = sharedObj testTable["key2"] = MyObj(age: 32) testTable["key3"] = sharedO

Stock address instead of plain object in a table : C to Nim

> The reason for this is because the object is declared as a ref object. I have no choice, my object is declared like this. The problem may be deeper than that: did I make the right choice in using a table to save my objects ??? Thanks for the link.

Stock address instead of plain object in a table : C to Nim

@Arak, my objects will all be different, so my table memory will increase. Am I right ? In my case, I did the same thing as you. But my code is a bit different, it's like I call it that (I don't know if there's any difference) side Nim. var testTable: Table[string, MyObj]

Stock address instead of plain object in a table : C to Nim

Well they need to exist _somewhere_. The code I shared above only stores a reference to the object in the table, the object itself lives on the heap. The reason for this is because the object is declared as a `ref object`. If you try to change that to just `object` then you will see the program

Stock address instead of plain object in a table : C to Nim

@PMunch, sorry I don't understand , when you do this : var testTable: Table[string, MyObj] proc populateTable() = testTable["key1"] = MyObj(age: 42) testTable["key2"] = MyObj(age: 32) Run You are populating your table with objects, but imagine that

Stock address instead of plain object in a table : C to Nim

As I mentioned, the whole premise of what you're doing is incorrect, so solving the problems you are facing won't actually solve your problem. Instead try this: import tables type MyObj = ref object age: int var testTable: Table[string, MyObj] proc po

Stock address instead of plain object in a table : C to Nim

@PMunch , Thank you for your kindness, I think I understand, finally when in my table I declared the object, I made a copy like this : var testTable = initTable[string, myObj]() # First approach declared the whole object proc initTableObj (): cint = # ... testTable[