Skip to content

Define omc session cmd #282

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

syntron
Copy link
Contributor

@syntron syntron commented May 2, 2025

rename OMCSession base as OMCSessionCmd and restructure it such that it is an independend function which contains only the API calls to OMC (was the final state of PR #270)

based on PR #270, #273, #280 and #281

@syntron syntron mentioned this pull request May 2, 2025
@syntron syntron force-pushed the define_OMCSessionCmd branch 2 times, most recently from 0380177 to 7c66a53 Compare May 3, 2025 19:34
@syntron syntron closed this May 8, 2025
@syntron syntron force-pushed the define_OMCSessionCmd branch from 7c66a53 to 5d67225 Compare May 8, 2025 19:18
@syntron syntron reopened this May 8, 2025
@adeas31
Copy link
Member

adeas31 commented May 12, 2025

Time to rebase this one.

@syntron syntron force-pushed the define_OMCSessionCmd branch from 9a285ea to 1bbe520 Compare May 12, 2025 16:16
@syntron
Copy link
Contributor Author

syntron commented May 12, 2025

@adeas31 PR is rebased

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.

except subprocess.TimeoutExpired: gives the following type error,

C:\OpenModelica\OMPython>python
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr  8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from OMPython import OMCSessionZMQ
>>> omc = OMCSessionZMQ()
>>> omc.sendExpression("quit()")
>>> quit()
Exception ignored in: <function OMCSessionZMQ.__del__ at 0x000002873BE7C5E0>
Traceback (most recent call last):
  File "C:\OpenModelica\OMPython\OMPython\OMCSession.py", line 336, in __del__
TypeError: catching classes that do not inherit from BaseException is not allowed

Perhaps use only except subprocess:

@syntron
Copy link
Contributor Author

syntron commented May 13, 2025

Interesting from my look into the code it is the following class dependency:

subprocess.TimeoutExpired
=> SubprocessError
=> Exception
=> BaseException

So the error message is unexpected ...

Furthermore, the following code works:

`
import subprocess

print('START')

cmd = ['sleep', '30s']
seconds = 2

try:
output = subprocess.run(cmd, stderr=subprocess.STDOUT, timeout=seconds)
except subprocess.TimeoutExpired as ex:
print(f'Timeout: {ex} {type(ex)}')

print('Done')
`

It results in:

START
Timeout: Command '['sleep', '30s']' timed out after 1.9999794609975652 seconds <class 'subprocess.TimeoutExpired'>
Done

I also checked if wait() raises TimeoutExpired => Yes; see https://docs.python.org/3/library/subprocess.html#subprocess.Popen.wait

Tested with 3.13.3

@syntron
Copy link
Contributor Author

syntron commented May 13, 2025

@adeas31 could you retry with the latest commit added?

I think this is not related to the main code but to the handling of the last command you did:

omc.sendExpression("quit()")

This stops OMC, i.e. _omc is set to None

quit()

here, the destructor of the class (=> del()) is called, which in turn calls self.sendExpression("quit()") and it fails as _omc is no longer defined

I'm still not sure why TimeoutExpired is indicated as the source of the error ...

@syntron syntron force-pushed the define_OMCSessionCmd branch from 3638961 to ffffed1 Compare May 13, 2025 08:36
@syntron
Copy link
Contributor Author

syntron commented May 13, 2025

Updated with a more generic approach ...

@syntron
Copy link
Contributor Author

syntron commented May 13, 2025

@adeas31 Could it be that this is not really an error but more a python / debugger thing? I just noted that the test script (your code) runs fine if I 'run' it. Even if I stop in line 547: 'self._omc.close()' and after that run continue all is fine. Only if I do a step by step execution it fails ...

Thus, the latest commit is perhaps not needed at all ...

@adeas31
Copy link
Member

adeas31 commented May 13, 2025

Its still the same.
Definitely the issue is related to handling of quit() command.

@syntron
Copy link
Contributor Author

syntron commented May 13, 2025

@adeas31 Could it be that this is not really an error but more a python / debugger thing? I just noted that the test script (your code) runs fine if I 'run' it. Even if I stop in line 547: 'self._omc.close()' and after that run continue all is fine. Only if I do a step by step execution it fails ...

Thus, the latest commit is perhaps not needed at all ...

Just as Information: I'm using PyCharm and running the code in the debugger of the tool; it returns something like this

Exception ignored in: <function OMCSessionZMQ.del at 0x000001E7FEB911C0>
Traceback (most recent call last):
File "[...]\OMPython\OMCSession.py", line 330, in del
File "[...]\OMPython\OMCSession.py", line 525, in sendExpression
File "_pydevd_bundle\pydevd_pep_669_tracing_cython.pyx", line 449, in _pydevd_bundle.pydevd_pep_669_tracing_cython.py_line_callback
File "_pydevd_bundle\pydevd_pep_669_tracing_cython.pyx", line 169, in _pydevd_bundle.pydevd_pep_669_tracing_cython._getframe
AttributeError: 'NoneType' object has no attribute '_getframe'

Due to this error message, I think it is not OMPython related but an error of the 'quit()' command, i.e. the closing of the debugger

@adeas31
Copy link
Member

adeas31 commented May 13, 2025

Yes, the OMPython code itself is correct. The message shown is expected message. Here's the relevant portion of the docs:

Warning: Due to the precarious circumstances under which del() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead. Also, when del() is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the del() method may already have been deleted or in the process of being torn down (e.g. the import machinery shutting down). For this reason, del() methods should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the del() method is called.

So what we see is expected.

Thus, the latest commit is perhaps not needed at all ...

True.

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