I’ve got a strange problem since recently: Whenever I open scide I immediately get the message Interpreter has quit. [Exit code: 0] - nothing else happens. Interpreter is dead. I can’t boot it manually.
However, if I start sclang from commandline everything works as expected…
I’m not sure what has happened. I haven’t changed anything in my SC setup/installation. The only thing I did was to install a desktop client for a Nextcloud installation (I’m on Debian 13 with a mate desktop). I wouldn’t have expected that to interfere with my SC setup…
I have no idea on how to debug this issue. Could a debug build reveal some more infos?
Not explicitly. sclang just always loads my installed quarks. Respectively, they are of course loaded too when I start up scide. Just to make sure it’s not one of my quarks (or any of my other custom extensions) I’ve just created a config that loads no extensions at all - same output when I open scide. Interpreter quits immediately (or doesn’t even boot at all?). sclang on the commandline, however, isn’t affected at all (boots fine, scide config isn’t considered at all, loads all quarks. Can execute sclang code).
I’ve got a strange problem since recently: Whenever I open scide I immediately get the message Interpreter has quit. [Exit code: 0] - nothing else happens. Interpreter is dead. I can’t boot it manually.
However, if I start sclang from commandline everything works as expected…
Do you get some messages when you start scide from the commandline?
For example I get for a functional scide
$ scide
[1183396:7:1229/210411.747658:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
[…]
I’m not sure what has happened. I haven’t changed anything in my SC setup/installation. The only thing I did was to install a desktop client for a Nextcloud installation (I’m on Debian 13 with a mate desktop). I wouldn’t have expected that to interfere with my SC setup…
Did you install that client as debian package? If yes, did it install
dependencies? Does uninstalling the package affect scide startup
behavior?
if i rename the sclang binary here on macos to -sclang and boot the IDE i also get Interpreter has quit. [Exit code: 0] as the only message. so it could be that it-s a path issue where your IDE can-t find sclang.
Do you get some messages when you start scide from the commandline?
No, none.
Did you install that client as debian package? If yes, did it install
dependencies? Does uninstalling the package affect scide startup
behavior?
Yes, it was sudo apt install caja-nextcloud. It installs a number of dependencies. Meanwhile I purged everything again, rebooted. No luck. Interpreter still exits when I start up the IDE.
Did you install that client as debian package? If yes, did it install
dependencies? Does uninstalling the package affect scide startup
behavior?
Yes, it was sudo apt install caja-nextcloud. It installs a number of dependencies. Meanwhile I purged everything again, rebooted. No luck. Interpreter still exits when I start up the IDE.
Thanks for trying. I am out of ideas now. Hoping more ppl will chime in in
helping. All the best, P
I don’t think that’s possible, based on your command-line test.
Since sclang in the terminal works fine, we know two things: 1/ there’s an executable called sclang (hasn’t been renamed) and 2/ this executable lives in one of the system PATH directories.
Now, possible things that could go wrong with those: with 1/, there could be multiple sclang executables and the IDE might be trying to launch the wrong one (version mismatch) – however that should result in Document errors, not a hard crash, or with 2/ maybe the PATH is set in the terminal session (by a shell profile script, for instance), but the PATH variable might not be the same when running the IDE. I can’t say that’s terribly likely (since sclang is supposed to be in /usr/local/bin and it’s almost impossible to imagine this not being in your PATH, I’d say it’s highly unlikely), but if sclang is outside of the system PATH except for a terminal-specific setting, that might match the symptoms.
that-s what i suspect: the installation of the nextcloud desktop client did somehow mess up the configuration of path-variables for the window manager in such a way that sclang is only in the path when launched from the terminal. @nufets: what happens if you try to launch scide from the terminal? I can do this on my system like this:
2/ maybe the PATH is set in the terminal session (by a shell profile script, for instance), but the PATH variable might not be the same when running the IDE.
Ouch. That would be really nasty. But makes sense.
Just to recapitulate: I can start sclang on commandline. I can start scidefrom commandline (no errors, no messages). Its behavior regarding sclang, however, is just the same as if I had started it from my desktop (sclang exits immediately).
scide is very opaque here as it gives no insight on where it looks for sclang, respectively, there seems to be no possibility to tellscide where to look for sclang (I vaguely remember that there was once some problem with webkit (?) in the help browser, which I was able to work around by adding some option to the scide call. Unfortunately I don’t remember anymore what that was. Calling scide --help doesn’t give any useful information).
If you start ./sc-ide from within a terminal it will be hydrated with the PATH variable of your shell. If you are able to start sclang -h, it should also be possible to do this within sc-ide then.
You should that you did not mix up your class library and sclang version - the class library should be 3.13 since trixie ships with 3.13.0.
If you have for some reason a 3.14.0 class library it would result in a crash.
You should also check the values in sc_ide_conf.yaml (I do not know where this file is located in Debian, you should search for it).
Maybe interpreter.configFile is non-existing or malformed, or sclang does not have permissions for interpreter.runtimeDir.
This is most likely unrelated - the error code is already different.
Hmmm… that’s what I would have assumed as well. But it (currently) isn’t the case. I can startup sclang from commandline but fails in the IDE.
You should that you did not mix up your class library and sclang version - the class library should be 3.13 since trixie ships with 3.13.0.
If you have for some reason a 3.14.0 class library it would result in a crash.
I’m not using the SC package coming with trixie - I’ve compiled SC 3.14.1 from sources (sorry for not mentioning that earlier). I’ve already uninstalled and reinstalled a couple of times. No luck so far.
I’ve already been looking at that file and don’t see what should go wrong here.
You should also check the values in sc_ide_conf.yaml (I do not know where this file is located in Debian, you should search for it).
I have already created a sc_ide_conf.yaml with all extensions (quarks and other custom classes) deactivated. That didn’t work either.
Maybe interpreter.configFile is non-existing or malformed, or sclang does not have permissions for interpreter.runtimeDir.
What is the interpreter.configFile? Is that the sc_ide*.yaml that I create within the preferences? How can I check the permissions the interpreter.runtimeDir? (where is the interpreter.runtimeDir?)
My best guess would be to check out the configFile and see if you can start the interpreter with this config file from the terminal. Also check out if you can start with -i scqt from within the terminal as this would indicate that the Qt<->sclang communication is the culprit.
Interestingly enough sclang seems to always use the / as working directory (which seems not like a good default?) - at least on macOS.
If you can start sclang via
cd /
sclang -l <your_config_path> -i scqt
then there is indeed something wrong on how sc-ide spawns sclang - but this would be the best way to replicate sc-ide behavior outside of sc-ide.
If you build it yourself you can also use a debugger - on macOS it is possible to wait for a yet unstarted process w/ a debugger, not sure if this is also possible on linux/gdb.
… I had totally overlooked that I still had the path to my old runtime environment in my config. In the config excerpt above the runtimeDir is set to "". Mine was set to a path which wasn’t correct anymore. Obviously, if it’s set to a path (it can be empty as well) the path must exist. The term runtimeDir is a bit confusing, I think. In the sources it is referenced as workingDirectory.
Anyway, wouldn’t it be possible to post a more informative error message in case runtimeDir isn’t found? To me it looks like it should be (though I don’t know much about C/C++. I might try to fix this when I find time. Don’t feel rushed).