-
Notifications
You must be signed in to change notification settings - Fork 110
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
base: master
Are you sure you want to change the base?
randr: inherit XError in error classes #242
Conversation
ef0cc66
to
9a6fc9c
Compare
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. |
@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
9a6fc9c
to
52800b1
Compare
Codecov Report
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 |
|
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. |
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 ;). |
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.
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.
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) |
@vasily-v-ryabov Any chance this will be considered for merge? Or should I just downgrade? |
@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? |
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). |
@benoit-pierre do you also have write access to this repository? |
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? |
I have no idea what the plan is for this repository. |
Neither do I, but I wouldn't expect such a PR to get merged. At least not any time soon. |
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 |
@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/ |
@Avasam Would be grateful if you could help out advancing the fork in any way and testing its reliability. |
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. |
@petli are you in a position to do something about the maintainer issue? Or would we need to contact @vasily-v-ryabov for that? |
@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? |
@petli That sounds like a good idea, not sure where or how at this point, though |
@petli @fransklaver Discussions are not available in the GitHub repository, apparently (need to enable). Really keen about someone being able to maintain. |
@ehfd @fransklaver I've enabled discussions now, wasn't aware that I needed to do it first, and posted #273 there. |
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
fixes #241