Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Communicate with sclang via TCP #45

Open
crucialfelix opened this issue Jun 22, 2019 · 7 comments
Open

Communicate with sclang via TCP #45

crucialfelix opened this issue Jun 22, 2019 · 7 comments

Comments

@crucialfelix
Copy link
Owner

crucialfelix commented Jun 22, 2019

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 crucialfelix changed the title Merge sockets pr TCP port communication Jun 22, 2019
@crucialfelix crucialfelix changed the title TCP port communication Communicate with sclang via TCP Jul 6, 2019
@crucialfelix
Copy link
Owner Author

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
Copy link

htor commented Oct 5, 2019

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link

htor commented Oct 5, 2019

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
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants