Can sclang detect the IDE which is currently using?

Hi there,

Is it possible to tell sclang

  • which editor it is currently using
  • which editor the current document is opened in, or
  • which editor the current code is being evaluated in?

While testing various things in SC-IDE, vscode and vscodium, I have a problem due to s.waitForBoot in the startup.scd file in the Platform.userAppSupportDir. They are all trying to boot servers on the same port number. It would be great if sclang could detect which IDE is currently being used, then I could set a different server port per IDE. Is this possible?

http://doc.sccode.org/Classes/Platform.html#*ideName

The list of IDEs here is out of date. I’d suggest to run Platform.ideName in each editor to find out what the string is. SC-IDE I believe is "scqt".

I guess you’ll get the same string for both of these. Is there a reason to run both at the same time?

hjh

Thank you!

Yes, they both return vscode. Unless there is a way to get the path of the IDE, there is no way to make sclang distinguish between vscode and vscodium.
The first purpose of using vscode and vscodium at the same time is to search for text in different project folders. Probably I should rearrange my project folder…

Here’s an idea: Instead of distinguishing editors, how about distinguishing active sclang clients based on langPort (which must be unique)?

Server.default.addr = NetAddr("127.0.0.1", NetAddr.langPort - 10);
s.boot;

// sc-ide:
Booting server 'localhost' on address 127.0.0.1:57110.

// vscodium:
Booting server 'localhost' on address 127.0.0.1:57111.

hjh

1 Like

Thank you so much! It is a perfect solution! Amazing!!
There is still a problem. SC-IDE will not start while vscode-sclang is running. So the correct steps are as follows:

  1. Start SC-IDE.
  2. Start VScode and run sclang.

If SC-IDE is quit, one should quit VScode to be able to start SC-IDE.

I suspect a port conflict. With default settings:

  1. Start VSCode. sclang takes port 57120.
  2. Start SC-IDE. 2nd sclang should take port 57121.

I have something in my startup.scd to kill sclang processes if SC-IDE’s sclang doesn’t get 57120. If I remove this, then it all works. If I enable it, then it’s broken. This is a startup.scd customization on my side, so SC isn’t responsible for it.

So there must be something in your system interfering with the normal logic. What that is, based on available information, I couldn’t guess.

hjh

1 Like

The problem was there before I used your solution.

Using the terminal command lsof -i :57120 I can see if port 57120 is open. After starting sclang in the terminal with the default port 57120, I can start sclang in VScode and VScodium.However, SC-IDE does not start in the same state. This is bizarre. I only have this problem on MacOS. On Ubuntu, SC-IDE starts in any order.

(base) prko@prkoMBP2021 ~ % lsof -i :57120
(base) prko@prkoMBP2021 ~ % lsof -i :57121
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
sclang  37154 prko   13u  IPv4 0xa71da5392c0de8e9      0t0  UDP *:57121
scsynth 37309 prko   13u  IPv4 0xa71da5392c0de8e9      0t0  UDP *:57121
(base) prko@prkoMBP2021 ~ % lsof -i :57122
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
sclang  37342 prko   13u  IPv4 0xa71da5392c0b38e9      0t0  UDP *:57122
scsynth 37504 prko   13u  IPv4 0xa71da5392c0b38e9      0t0  UDP *:57122
(base) prko@prkoMBP2021 ~ % sclang
compiling class library...

My guess is that the unique structure of the MacOS application and SuperCollider.app prevents SC-IDE from starting if sclang, which resides in the same location as SC-IDE, is already running:

On MacOS, the executable name of the SuperCollider IDE is SuperCollider, and it is in the same location as sclang: SuperCollider.app/Contents/MacOS'. scsynth is in SuperCollider.app/Contents/Resources’.

Note that SuperCollider.app has two executables in this location, while there is normally only one executable in `xxx.app/Contents/MacOS’.

The following phenomenon may be evidence of this:
I have two instances of SuperCollider.app on my MacOS: SuperCollider 3.13.0 and 3.14.0_dev. I only use the latter.

As a test, I did the following:

While sclang in SuperCollider.app in the SC 3.14 folder was running in vscode or in the terminal, I double-clicked on SuperCollider.app in the SC 3.13 folder. SuperCollider 3.13.0 was launched!!! I think this phenomenon supports my hypothesis.

So, to solve this problem, it seems you need to move sclang to SuperCollider.app/Contents/Resources.

I wrote an issue on github: