I am looking at code like
https://github.com/trampgeek/jobe/blob/master/application/controllers/restapi.php#L53
And
https://github.com/trampgeek/jobe/blob/master/application/libraries/octave_task.php#L25
And it seems that JOBE always reports all languages as installed. What am I missing?
You're not really missing anything, except your definition of installed might be a bit different from mine.
Jobe reports as "installed" all the languages for which a <language>_task.php file exists. If Jobe is installed using the apt install commands in the documentation, the set of language task files should match the set of languages actually installed on the server.
There's also a folder libraries/DisabledLanguageTasks. If you don't want to support a particular language in Jobe you should move the language task PHP file into that folder. You'll see there's a file matlab_task.php in there already because Matlab isn't installed by default, for obvious reasons.
Reporting of language version numbers is essentially nonsense. In a rare act of self-discipline, I wrote the API spec before implementing Jobe. I specified that both the language name and the language version number would be returned on a GET LANGUAGES request. However, CodeRunner doesn't use the version numbers so I then just hard-coded whatever version was currently installed. It might have been less confusing if I'd just returned a zero in all cases.
Changing the getVersion method to return the actual version number for each language wouldn't be hard, but it wouldn't actually achieve anything, either.
Richard
Thanks for explaining. What you describe is logical, but not what we want. We would rather not change any of the JOBE files checked out of git.
In an ideal world, getVersion actually do gcc --version, or whatever, and either return the right version, or null if it is not there. Then that could be used to better initialise the language list.
Alternatively, could we have a config file (not it git) that lists which languages you want enabled/disabled. I could be called enabled-languages.php, and there could be an example enabled-languages.dist.php file in git. (Perhaps the install script could set up this config file?)
Fair enough. I did have a few guilt qualms while writing my first response.
I just implemented the "ideal world" solution, which was easy enough. But having done so, I remembered why I hadn't done that in the first place. When testing a question submission, CodeRunner begins by asking all enabled sandboxes what languages they support. [That's necessary to handle remote reconfigurable sandboxes like Ideone or even Jobe.] The ideal world implementation of GET LANGUAGES then queries all language subsystems to see if they're available and if so what version. Matlab alone takes 2 seconds to trundle into life, so the performance hit from this approach is unacceptable.
A configuration file approach would work but it's an additional complexity I'd prefer to avoid, and requires manual updating when language versions change. I'd much prefer to find a way to cache the GET LANGUAGES response in an acceptable manner. I'm sure I can find a way, but I want to think about it for a bit. Stay tuned.
Richard