It seems to do rather well.
On Wednesday, 6 April 2016 08:29:07 UTC-7, Francis Avila wrote:
>
> On Monday, April 4, 2016 at 6:30:07 PM UTC-5, Howard M. Lewis Ship wrote:
>>
>> David Nolen had an early ClojureScript core.async demo with thousands of
>> channels, controlling individual pixels.
>>
>
On Monday, April 4, 2016 at 6:30:07 PM UTC-5, Howard M. Lewis Ship wrote:
>
> David Nolen had an early ClojureScript core.async demo with thousands of
> channels, controlling individual pixels.
>
This is the demo you are referring to:
http://swannodette.github.io/2013/08/02/10-processes/
You should perhaps look at github.com/walmartlabs/active-status if you want
a way to figure out what all those processes are doing.
I'd say the things we've worked on have had dozens of channels, and often
common core.async primitives (such as into, pipe, etc.) create additional
channels and CSPs
This thing just an idea at this point. Basically, your typical game loop
will consist of iterating over a collection of objects and calling some
kind of update operation on each. I would like to replace this with
asynchronous signaling. Signaling could include messages like "update this
obje
Without knowing too much about the internals, but having used
core.async/channels a lot, I don't think "hundreds" of channels will be a
problem ever. However, as always the devil is in the details. People might
be able to give better feedback if you give more details about your use
case.
On S
Lately, I've been working on a game in Clojure, and I've been trying out
various ways of modelling the game state and objects.
One of these ideas is to give each object its own channel and make a fully
asynchronous architecture.
I would like to know if having potentially hundreds of channels o
