Communicate with sclang via TCP

[crucialfelix]

Copy the TCP connection from #37

This fixes problems with large messages breaking. sclang cuts off .postln if the content is too big.

Should be able to use the TCP also for returning Error results (as JSON).

Probably without the state machine changes, but I want to think through his PR more.

[crucialfelix]

Hey Jacob @woolgathering I see you wrote some code to break up large code into smaller chunks and then concat and execute them. If I understand correctly, then I think the PR from @ssfrr will fix your problem.

[htor]

hi! curious about this new socket architecture. but first, how does supercolliderjs work with sclang today? is there an intro somewhere? would the overall architectural difference using sockets for i/o be very different from today? would it be less of an hack maybe?

i read some issues regarding problems with long strings passed through stdio/stdin and it seems to me as it would be more reliable and stable to use sockets for ipc!

[crucialfelix]

Currently it posts responses to STDOUT with some text marker boundaries. This identifies the response (with a guid) so that it can be paired up with the call.

The exception handler is patched so that it posts a JSON of the full call stack with each frame. This is more than you usually get posted by sclang. It's used in my atom-supercollider IDE as well.

This posting to STDOUT is easily breakable because of issues in sclang itself that.

JMC figured (quite rightly) that music is more important than printing so printing gets cancelled if it's time to render audio buffers. There are some other messy issues where posting gets mangled and interspersed.

[crucialfelix]

The TCP code Spencer wrote in #37 is great, but there were a few issues that stopped me from being able to merge it.

1. You could only run one sclang at a time because the port number is fixed. Unix file sockets would fix that. eg. @/supercollider/pid

2. It causes the state machine to switch a lot. The state machine was intended to only represent the major lifetimes states: compiling, compile-errors, ready etc.

Making this work won't be too hard.

[crucialfelix]

As you may have noticed I have a nearly ready 1.0-alpha release ready. It's all in TypeScript now. I have some plans, but not really much time. I will get 1.0 out by the end of the year. The API will not change at all, so it should not disturb anybody working on anything.

[htor]

thanks for the explanation. now i get it.

Making this work won't be too hard.

i see, do you plan to make a new pr the sockets, or do you need help for completing that particular pr? would be happy to join the discussion nonetheless

As you may have noticed I have a nearly ready 1.0-alpha release ready.

this is really nice. where could i see this nearly ready 1.0-alpha release? i see https://github.com/crucialfelix/supercolliderjs/tree/feature/flow-to-typescript is merged, but are you referring to the lerna branch?

[crucialfelix]

It's this PR: #53 Basically done, needs a final check.