Generators not supported over the network yet

[boutell]

I had an idea for a way to make generators work over the network and I couldn't get it out of my head so I wrote some proof of concept code:

https://gist.github.com/boutell/59716a582da7c7f4884b

The basic concept is this: each active generator is represented by an object. The object contains the state of the generator, and also contains a "step" function which can be used to generate the next value.

After that the challenge is to serialize this state over the network. To do that, I add a "source" property which is the source code of "step" as obtained via "toString".

Since "step" never relies on a closure, but rather just manipulates the state object that is passed to it on each call, it is possible to reconstruct both the code and the current state of the generator on the receiving end.

The most daunting challenges not answered here:

• The second computer will alter the state of the generator; that must be communicated back to the first computer.
• Each invocation of the generator on either computer should probably result in a network message to the other computer.
• Timing probably matters a whole heckuva lot, since generators can be invoked on every sixteenth note.

But those things are possible in principle with this hack.

[boutell]

The other weird thing worth mentioning is that I attach the state of the generator to the generator function as a property. And when I'm ready to send the current state of all generators "over the network," I do so with a JSON.stringify call that takes advantage of the second parameter to spot those functions, which can't go over the network, and replace them with the state object, which can.

[kylestetz]

Finally dug into this, thanks for the example!

So the issue turns out to be a little different thanks to a few assumptions we are allowed to make...

This proof of concept relies on one computer producing the sound and all other computers observing and contributing function calls. On all of the slave machines, the call doesn't do anything other than announce itself over the socket.

This is good— we don't have to keep state on any of the slave machines. All they are capable of doing is providing the initial context.

The challenge, then, is in communicating that a particular argument is a generator function (that has its own arguments). Generator functions on the slave machines could be overridden so that all they do is return e.g. (in the case of the step function) 'step(0,1,10)', a string which can be evaled on the master machine.

[boutell]

That does sound a lot simpler!

On Mon, Dec 22, 2014 at 5:48 PM, Kyle Stetz notifications@github.com
wrote:

Finally dug into this, thanks for the example!

So the issue turns out to be a little different thanks to a few
assumptions we are allowed to make...

This proof of concept relies on one computer producing the sound and all
other computers observing and contributing function calls. On all of the
slave machines, the call doesn't do anything other than announce itself
over the socket.

This is good— we don't have to keep state on any of the slave machines.
All they are capable of doing is providing the initial context.

The challenge, then, is in communicating that a particular argument is a
generator function (that has its own arguments). Generator functions on the
slave machines could be overridden so that all they do is return e.g. (in
the case of the step function) 'step(0,1,10)', a string which can be evaled
on the master machine.

—
Reply to this email directly or view it on GitHub
#6 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com