| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. Nice fix. I checked the RLE boundary case locally and it held up.
Sorry, something went wrong.
There was a problem hiding this comment.
Some minor comments
Sorry, something went wrong.
|
Amazing! great job! |
Sorry, something went wrong.
|
Thanks @maurycy for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15. |
Sorry, something went wrong.
|
GH-153047 is a backport of this pull request to the 3.15 branch. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #151378
I've described the root cause in #151378.
Instead of adding some LIMIT and checking it, I'm doing two tricks here that spare us one struct and some complexity: using a fixed buffer (lazy alloc, so threads do not pay any price if there's no repeats), instead of a dynamic array, and eager encoding, instead of having PendingRLESample.
Truth be told, it's not easy to write a test. We currently have no test for any OverflowError
Also, I'm wondering if we couldn't simplify alloc-dealloc in the reader, too:
cpython/Modules/_remote_debugging/binary_io_reader.c
Lines 1098 to 1114 in ee78d43
cpython/Modules/_remote_debugging/binary_io_reader.c
Line 958 in ee78d43
but it's out of the current scope (and maybe PyList_New(run_len) would be sufficient there; just call it a day.)
(No) reproduction
The same as in #151378