Skip to content

randr: inherit XError in error classes #242

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 1 commit into
base: master
Choose a base branch
from

Conversation

fransklaver
Copy link

@fransklaver fransklaver commented Nov 8, 2022

Commit c87624d ('Add Randr error classes and register them during init') introduces three new error classes to xrandr, but makes them inherit from Exception.

Let all error classes in randr inherit from Xerror, like all other code expects.

Fixes the traceback

...
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/display.py", line 182, in sync
        self.get_pointer_control()
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/display.py", line 833, in get_pointer_control
        return request.GetPointerControl(display = self.display)
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/rq.py", line 1369, in __init__
        self.reply()
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/rq.py", line 1381, in reply
        self._display.send_and_recv(request = self._serial)
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 612, in send_and_recv
        gotreq = self.parse_response(request)
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 719, in parse_response
        gotreq = self.parse_error_response(request) or gotreq
      File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 745, in parse_error_response
        req = self.get_waiting_request(e.sequence_number)
    AttributeError: 'BadRRModeError' object has no attribute 'sequence_number'

fixes #241

@fransklaver fransklaver force-pushed the randr-errors-inherit-xerror branch 2 times, most recently from ef0cc66 to 9a6fc9c Compare November 8, 2022 11:46
@Avasam
Copy link
Contributor

Avasam commented Nov 16, 2022

I've noticed this as well while working on type definitions. extension_add_error should expect a XError, but BadRROutputError, BadRRCrtcError and BadRRModeError aren't.

What about the other Error classes?
image

@fransklaver
Copy link
Author

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

They didn't crash my program, and as these specific classes had been added recently, I hadn't bothered to look any further. Feel free to fix the others too.

@vasily-v-ryabov
Copy link
Collaborator

@fransklaver thanks for the fix! Please resolve conflicts before merging it.

Commit c87624d ('Add Randr error classes and register them during
init') introduces three new error classes to xrandr, but makes them
inherit from Exception.

Let all error classes in randr inherit from Xerror, like all other code
expects.

Fixes the traceback

```
...
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/display.py", line 182, in sync
    self.get_pointer_control()
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/display.py", line 833, in get_pointer_control
    return request.GetPointerControl(display = self.display)
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/rq.py", line 1369, in __init__
    self.reply()
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/rq.py", line 1381, in reply
    self._display.send_and_recv(request = self._serial)
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 612, in send_and_recv
    gotreq = self.parse_response(request)
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 719, in parse_response
    gotreq = self.parse_error_response(request) or gotreq
  File "/tmp/python-env/lib/python3.8/site-packages/Xlib/protocol/display.py", line 745, in parse_error_response
    req = self.get_waiting_request(e.sequence_number)
AttributeError: 'BadRRModeError' object has no attribute 'sequence_number'
```

fixes python-xlib#241
@fransklaver fransklaver force-pushed the randr-errors-inherit-xerror branch from 9a6fc9c to 52800b1 Compare December 25, 2022 21:24
@codecov-commenter
Copy link

Codecov Report

Merging #242 (52800b1) into master (4e8bbf8) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #242   +/-   ##
=======================================
  Coverage   78.21%   78.21%           
=======================================
  Files          42       42           
  Lines        4705     4705           
=======================================
  Hits         3680     3680           
  Misses       1025     1025           

@petli
Copy link
Contributor

petli commented Dec 28, 2022

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

XError represents errors that are returned from the server and is deserialised from the protocol error message, while the other ones are client-side errors where none of that information is available. Thus it wouldn't make sense to use XError as the base for all exceptions in Xlib, but a new intermediary exception class could be introduced for that purpose if that would be useful (maybe XlibError or XlibException, or maybe there's some other recommendations in modern Python).

@fransklaver
Copy link
Author

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

XError represents errors that are returned from the server and is deserialised from the protocol error message, while the other ones are client-side errors where none of that information is available. Thus it wouldn't make sense to use XError as the base for all exceptions in Xlib, but a new intermediary exception class could be introduced for that purpose if that would be useful (maybe XlibError or XlibException, or maybe there's some other recommendations in modern Python).

That's basically what I meant, yes. If they won't be treated like they're XErrors, there is no point in having them inherit XError. For clarity it could be useful to introduce an intermediate layer, I agree.

@petli
Copy link
Contributor

petli commented Dec 28, 2022

That's basically what I meant, yes. If they won't be treated like they're XErrors, there is no point in having them inherit XError.

I see, sorry for the misunderstanding! My brain haven't fully booted up today.

@fransklaver
Copy link
Author

I see, sorry for the misunderstanding! My brain haven't fully booted up today.

No worries. It only clarifies stuff for other people whose brains haven't fully booted yet ;).

t-wissmann added a commit to herbstluftwm/herbstluftwm that referenced this pull request Mar 9, 2023
In python-xlib 0.32, the bug python-xlib/python-xlib#242
was introduced which caused `test_floatplacement_smart_create_many` to
fail deterministically. There already is a pull request in `python-xlib`
with a fix, but it is not merged yet. So for the time being, let's
simply use the old python-xlib version.
mergify bot pushed a commit to herbstluftwm/herbstluftwm that referenced this pull request Mar 9, 2023
In python-xlib 0.32, the bug python-xlib/python-xlib#242 was introduced which caused `test_floatplacement_smart_create_many` to fail deterministically. There already is a pull request in `python-xlib` with a fix, but it is not merged yet. So for the time being, let's simply use the old python-xlib version.
@ErikBjare
Copy link

ErikBjare commented Aug 28, 2023

Is this not being considered for merging? We're facing #241 / #259 in our project where our end-users have spuriously had processes hang at 100% CPU until restarted.

We are considering pinning 0.31 until a fix is released. However, we ourselves have a slow release cycle with lots of testing/prereleases, so hoping someone can pick this up before we ship a stable one. (as others seem to have done already in herbstluftwm/herbstluftwm#1544)

@ErikBjare
Copy link

@vasily-v-ryabov Any chance this will be considered for merge? Or should I just downgrade?

@fransklaver
Copy link
Author

@ErikBjare We've had the version pinned to 0.31 ever since I stumbled upon this issue. The previous release should really have included this fix, and upon request I updated the pull request as soon as I could. I haven't had any further communication about this from @vasily-v-ryabov either.

@vasily-v-ryabov do you need help maintaining this project?

@ErikBjare
Copy link

ErikBjare commented Sep 13, 2023

Looking at the commit history there have been no new commits on master since December?

Not holding my breath. Saw that last commits were co-authored by Vasily, figured I would ping.

Given the stability of the Xorg/xlib APIs we use, we might keep the version pinned for a long time to prevent further issues (as issues would lead to data loss in our case).

@ehfd
Copy link

ehfd commented Nov 25, 2023

@benoit-pierre do you also have write access to this repository?

@redhog
Copy link

redhog commented Apr 29, 2024

Heys! I was planning to make a PR for some convenience syntax sugar stuff, but the commit history of master and the above comments don't look promising / makes this look pointless. What is the plan for maintaining this library? Does anybody know?

@fransklaver
Copy link
Author

I have no idea what the plan is for this repository.

@ErikBjare
Copy link

Neither do I, but I wouldn't expect such a PR to get merged. At least not any time soon.

@ehfd
Copy link

ehfd commented May 1, 2024

https://github.com/selkies-project/python-xlib/pulls?q=is%3Apr

I just merged all trivial PRs to my organization's fork. I can give out write access. @Avasam @fransklaver

Use python-xlib @ https://github.com/selkies-project/python-xlib/archive/master.zip for setuptools or pip.

@Avasam
Copy link
Contributor

Avasam commented May 2, 2024

@ehfd This repo does look unmaintained, if not abandoned. I'm mostly interested in #251 . Which I could rewrite much better if you're willing to drop EOL Python (or at least anything under 3.7)

In the mean time, I added stubs to typeshed: https://pypi.org/project/types-python-xlib/

@ehfd
Copy link

ehfd commented May 2, 2024

@Avasam
I had to revert your commits (but nonetheless preserved this one) because one of them showed some new regressions with my project with capturing the cursor image consistently. I'd like to check which commit it is when I have time.

Would be grateful if you could help out advancing the fork in any way and testing its reliability.

@petli
Copy link
Contributor

petli commented Jul 5, 2024

Speaking as the original author and lapsed maintainer (e.g. coming very late to this thread) this library would really need some active maintainers. I don't use XWindows anymore myself, and I think @vasily-v-ryabov has said something along the same lines.

@fransklaver
Copy link
Author

@petli are you in a position to do something about the maintainer issue? Or would we need to contact @vasily-v-ryabov for that?

@petli
Copy link
Contributor

petli commented Jul 5, 2024

@fransklaver I think I count as a maintainer still and could add new ones to the project. I would have to look at pypi publishing, I'm not sure if I have any permissions there. Maybe move this into a discussion thread for visibility?

@fransklaver
Copy link
Author

@petli That sounds like a good idea, not sure where or how at this point, though

@ehfd
Copy link

ehfd commented Jul 5, 2024

@petli @fransklaver Discussions are not available in the GitHub repository, apparently (need to enable). Really keen about someone being able to maintain.

@petli
Copy link
Contributor

petli commented Jul 8, 2024

@ehfd @fransklaver I've enabled discussions now, wasn't aware that I needed to do it first, and posted #273 there.

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.

0.32 throws AttributeError: 'BadRRModeError' object has no attribute 'sequence_number'
8 participants