ServerConfig

[manuEbg]

We need a Server Config Class/File should contain:

• Path to omc Executable
• port
• locale ?

[IlmarB]

So I have started an attempt - referencing to the mope.cfg file of the mope-server I can easily create the needed server.cfg. But .. What I do not understand is the constructor of OMCAdapter-Class. So @CSchoel, what exactly is the purpose of the parameters in class MopeLSPServer

workspaceService.InitOMC( new OMCAdapter("/usr/bin/omc", "us", "mope_local" ));

and the definition in OMCAdapter

public OMCAdapter(String omcExecPath, String locale, String fileProviderSuffix){ omc = new ZeroMQClient(omcExecPath, locale, new ZMQPortFileProvider(fileProviderSuffix)); logger.info("OMCAdapter initialized"); }

[IlmarB]

I mean the first one is kinda self-explanatory, that is the path to the omc. But what about the other two?

[CSchoel]

I know as much about these classes as you, but by traversing a little through the code ("go to definition" is your friend :wink:) I found out the following:

• The locale is not uses for a java.util.Locale as I first suspected, but instead it sets the LANG environment variable for the OMC process. I guess this influences the language in which OMC reports errors.
• The ZMQPortFileProvider is a helper class that is used to find the ZMQ port file. As far as I understand, this port file is an actual file on the file system, which is used by ZMQ to communicate between processes. The OMC creates this file when it is started and the omc-java-api has to find it in order to establish a ZMQ connection to the OMC process. The default suffix is om_local. I am not sure if this suffix can change depending on the OS or OMC arguments. You have to figure that out by trial and error unless @njustus has documented this somewhere or you can find the information in the OpenModelica documentation.
• I would suspect that most of the time you will not need those arguments at all. You can simply create a client with new ZeroMQClient(omExecPath) and it will use the LANG variable of the OS and the default suffix om_local.

[manuEbg]

@IlmarB maybe this is a little help:) https://github.com/MopeSWTP-SS21/LspConsole/commit/dd7a1c3161435c787ab49adc3e30df47f7c1176b

I got inspired by https://stackoverflow.com/questions/16273174/how-to-read-a-configuration-file-in-java

[njustus]

I guess this influences the language in which OMC reports errors.

Yes it does! If you do not provide the LANG variable on localized systems omc produces half-localized error messages. They are mostly unreadable.

If you don't need to support multiple projects at once, you don't need the parameter suffixProvider. In this scenario you need unique port files per project which is highly application specific. If the suffix isn't provided omc will always reuse the running instance, which in turn causes race condition nightmares!

I would suspect that most of the time you will not need those arguments at all. You can simply create a client with new ZeroMQClient(omExecPath) and it will use the LANG variable of the OS and the default suffix om_local.

Yes!

BTW: I would highly recommend using HOCON or YAML for your configuration files. Unless you are using Spring Boot for parsing property files into @Configuration classes its extremely difficult to use them consistently throughout your application.

Sidenote: Skimming through the mope and webmodelica thesis could improve your understanding of Modelica and OMC.

[CSchoel]

@IlmarB This issue has not received any updates in the last week. What is your status?

[CSchoel]

Currently, the server config is loaded from src/main/java/Server/server.config. This is bad practice, because:

• It assumes that everybody who wants to run the server has the source files lying around next to the server executable.
• It conflates data and code directories.
• It does not follow common operating system conventions for storing configuration data of applications (e.g. most Linux systems use a file like ~/.mope or ~/.config/mope/mope.conf, while windows uses something like %APPDATA%\mope\mope.conf). Note: If you should choose the ~/.config/mope/mope.conf route on linux, please make sure that either a) your config is compatible with the old Mo|E version by nico, or b) you choose a slightly different name than mope for the directory.

[IlmarB]

nothing done for that yet

[CSchoel]

@IlmarB It has been another week without update. Can you please keep us posted about the status of this issue?

[IlmarB]

I actually forgot about this one 🙈 will do until friday

[IlmarB]

done - see branch feature/cfgAndShutDown