Package name and file name convention for Nim

I always use camel-case for consistency as I also use it when writing actual code. It is one less thought on something utterly meaningless that I can spare myself, while having at least something (the capitalization) to ease read-flow.

Introducing an async library inspired by Go in Nim

> the GoChannel will be a channel that detects when we are on a coroutine and > will suspend only the coroutine and not the thread. The dispatcher would have > the additional job to queue read available channels and resume the correspond > coroutines. I think a channel with 1 blocking receiver:

Experimenting with a SharedRc type

> ORC/ARC aren't safe against race conditions on the increment/decrement on > refs. So the GC_ref/GC_unref can run into race conditions. How I see, I haven't thought about it. Thanks !

Experimenting with a SharedRc type

You overuse `ref` afaict. For example, your `GoFile` could easily be an `object` (use `var T` parameter passing if you then need to update the object.)

Introducing an async library inspired by Go in Nim

Ah ah. I must admit I have just too much pleasure to work on my NimGo project. Not to hard but still challenging and very educational. std/tasks is very smart and good. But when I saw the compile time I freaked out a little. It cannot be used with NimGo where thousands to millions of procs must

Introducing an async library inspired by Go in Nim

> Is it worth your time 🙃 ? Nah, but I'm allowed to have fun. This would only be a side project for me. About closures and return values, that's why `std / tasks` is a thing.

Introducing an async library inspired by Go in Nim

Skipping the M:N model initially makes sense. It'd be pretty easy to end up with a ref shared between different coroutines running on different threads.

Experimenting with a SharedRc type

> It's quite easy to trick even ORC by using GC_ref in sender thread and > GC_unref in receiver thread. Not sure how safe it is tho ! ORC/ARC aren't safe against race conditions on the increment/decrement on refs. So the `GC_ref/GC_unref` can run into race conditions. You'd want to use `wasMove

Introducing an async library inspired by Go in Nim

On my first implementation, i tried to run the dispatcher in its dedicated thread. But it was quite dumb because all code ended up running inside this thread. For me the problematics are : * Is it really necessary ? Having a 1:N model doesn't prevent multithreading. But distribution of work

Experimenting with a SharedRc type

Hi elcritch, It's quite easy to trick even ORC by using `GC_ref` in sender thread and `GC_unref` in receiver thread. Not sure how safe it is tho ! I've created a Container object to allow this:

Introducing an async library inspired by Go in Nim

> It uses a 1:N model, where multiple coroutines must be confined into only one > thread It should use a M:N model though... How hard can it be? You need to protect the event loop with a lock and the scheduler can push runnable tasks to a thread pool. I'm willing to help. ;-)

Introducing an async library inspired by Go in Nim

@mratsim Thanks for having taken the time for your very detailed and informative response. Your knowledge and research are very valuable and far beyond mine. I have read with interest your work and must admit some are beyond my comprehension, and I look forward to see your weave-io baby born. H

🕹️ Setting up a project with NimForUE [Video]

I don't use NimForUE, but your presentation is very complete and well edited, nice work ! I liked you also mentionned corner case like what if our project uses already blueprint or what if NimForUe compilation crash Also good work from NimForUe developpers, seeing what Nim's metaprogramming can

Raising the IC feature again

Hello, I would like to ask what is the current state of incremental compilation? Was it implemented while I was away ;-) Looking at github issues, it seems it is partially implemented? I asked 'Claude.ai' about further optimizations inline with nim's design philosophy (that is, not too crazy st

Introducing an async library inspired by Go in Nim

Impressive work mate!

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. > > What I mean is that you can use stackful coroutines/fibers AND a > multithreading runtime to have parallelism. Ah yes, that's what I was trying to say. Go's runti

Nimsuggest and Manjaro Nim installation

The problem has been solved. Thanks to the team for the correction.

Cenforce 100: A Successful Treatment for Impotence in Men

Cenforce tablets are a useful treatment for male impotence and erectile dysfunction that aids in a man's ability to get and maintain an erection for more sexual engagement. By increasing blood flow to the penis, they do this. The medication should only be taken once every thirty to sixty minutes

Introducing an async library inspired by Go in Nim

> While go does not have user-visible coloring, it certainly has > calling-convention-coloring, meaning you cannot call Go functions from C. That's an order of magnitude better than having the coloring directly in your language! Besides, NimGo exists now and doesn't claim "don't use with C libr

Introducing an async library inspired by Go in Nim

@Ahogani > Well you can have both in the same program but I have never seen a > cooperative scheduling system to produce parallelism. What I mean is that you can use stackful coroutines/fibers AND a multithreading runtime to have parallelism. Now there seem to be a misalignment at what "cooper

Could Nim be used as the front-end for Taichi-lang?

> Is that too challenging for a beginner? Yes definitely but there are native Nim packages that offer DSLs for the GPU:

Could Nim be used as the front-end for Taichi-lang?

It looks really cool! However, it uses Python for the front-end… I’d like to use Nim instead. Is that too challenging for a beginner?