Skip to content

Conversation

@syntron
Copy link
Contributor

@syntron syntron commented Nov 23, 2025

The rework of OMCSessioZMQ was done with the idea in mind to separate the different backends and add new ones (Local/Port/Docker/DockerContainer/WSL). Thus, the structure of one main class (OMCSessionZMQ) and the backend/process classes (OMCProcess*) was developed.

Overall, this is not a good concept as the user has to create an instance of OMCProcess to provide it to an instance of OMCSessionZMQ if anything but the default (local) session should be used.

This PR is a draft of a (re)morge of the functionality - use one base class (OMCProcess here; to be renamed to OMCSession) which (1) contains the code needed by all backends and derived backend classes which have all functionality to replace OMCSessionZMQ.

Thus, the user has to only load / instanciate one class and can work with OMC ...

Follow-up PRs are work in progress; this is a breaking change for v4.1.0. In this release it will contain a compatibility layer (OMCSessionZMQ) whoch could be removed in v5.0.0.

The final version can be checked out in https://github.com/syntron/OMPython/tree/remove_OMCSessionZMQ

Please comment!

Copy link
Member

@adeas31 adeas31 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me.

As I understand, right now when the user creates OMCSessionZMQ it gets the default OMCProcessLocal. One can create different OMCProcess types like Local/Port/Docker/DockerContainer/WSL and can use them.

Now you want to remove OMCSessionZMQ and just use OMCProcess* and want to rename is to OMCSesssion* later on, right?

This sounds okay to me. Makes things slightly more convenient for the user.

@syntron syntron force-pushed the OMCSessionZMQ_merge_into_OMCProcess branch from cfac6f6 to beddea1 Compare November 24, 2025 20:55
@syntron
Copy link
Contributor Author

syntron commented Nov 24, 2025

This is correct! The challange here is, that we have the need to do some processing / definition of parameters before the ZMQ session can be started. The current solution uses two separate classes for it. This is quite easy to code but - as you wrote - hard to run.

The new solution uses metaclasses (__post_init__() functionality) to run the second class (setup of ZMQ session) within the base class after the parameters are defined. A little bit more complex but easier for the users.

@adeas31
Copy link
Member

adeas31 commented Nov 25, 2025

Is this ready to be merged?

@syntron
Copy link
Contributor Author

syntron commented Nov 26, 2025

Is this ready to be merged?

Yes it is; I will also prepare the follow up PRs

@syntron syntron mentioned this pull request Nov 26, 2025
@adeas31 adeas31 merged commit d590e64 into OpenModelica:master Nov 26, 2025
14 checks passed
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

Successfully merging this pull request may close these issues.

2 participants