| 1 |
W dniu sob, 02.09.2017 o godzinie 14∶23 -0700, użytkownik Zac Medico |
| 2 |
napisał: |
| 3 |
> On 09/02/2017 02:05 PM, Michał Górny wrote: |
| 4 |
> > W dniu sob, 02.09.2017 o godzinie 12∶19 -0700, użytkownik Zac Medico |
| 5 |
> > napisał: |
| 6 |
> > > On 09/02/2017 10:46 AM, Michał Górny wrote: |
| 7 |
> > > > dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that |
| 8 |
> > > > makes it unable to work with -OO code. Remove the optimizations from |
| 9 |
> > > > Portage shebangs to prevent triggering the issue until we find a proper |
| 10 |
> > > > solution for it. |
| 11 |
> > > > |
| 12 |
> > > > Bug: https://bugs.gentoo.org/628386 |
| 13 |
> > > > --- |
| 14 |
> > > > bin/clean_locks | 2 +- |
| 15 |
> > > > bin/dispatch-conf | 2 +- |
| 16 |
> > > > bin/ebuild | 2 +- |
| 17 |
> > > > bin/emaint | 2 +- |
| 18 |
> > > > bin/env-update | 2 +- |
| 19 |
> > > > bin/portageq | 2 +- |
| 20 |
> > > > tabcheck.py | 2 +- |
| 21 |
> > > > 7 files changed, 7 insertions(+), 7 deletions(-) |
| 22 |
> > > > |
| 23 |
> > > > diff --git a/bin/clean_locks b/bin/clean_locks |
| 24 |
> > > > index 13af06197..fb245972f 100755 |
| 25 |
> > > > --- a/bin/clean_locks |
| 26 |
> > > > +++ b/bin/clean_locks |
| 27 |
> > > > @@ -1,4 +1,4 @@ |
| 28 |
> > > > -#!/usr/bin/python -bO |
| 29 |
> > > > +#!/usr/bin/python -b |
| 30 |
> > > |
| 31 |
> > > The diff shows -O, but the commit messages says -OO, so which one is it really? |
| 32 |
> > |
| 33 |
> > Yes, it's a curious problem. -OO is the one breaking it but py<3.5 seems |
| 34 |
> > to be happy to load -OO files with -O: |
| 35 |
> > |
| 36 |
> > $ python2.7 -O -c 'import pycparser; print(pycparser.__file__)' |
| 37 |
> > /usr/lib64/python2.7/site-packages/pycparser/c_parser.py:20: RuntimeWarning: parsing methods must have __doc__ for pycparser to work properly |
| 38 |
> > class CParser(PLYParser): |
| 39 |
> > /usr/lib64/python2.7/site-packages/pycparser/__init__.pyo |
| 40 |
> > |
| 41 |
> > $ python3.4 -O -c 'import pycparser; print(pycparser.__cached__)' |
| 42 |
> > /usr/lib64/python3.4/site-packages/pycparser/c_parser.py:20: RuntimeWarning: parsing methods must have __doc__ for pycparser to work properly |
| 43 |
> > class CParser(PLYParser): |
| 44 |
> > /usr/lib64/python3.4/site-packages/pycparser/__pycache__/__init__.cpython-34.pyo |
| 45 |
> > |
| 46 |
> > This doesn't seem to be the case anymore for py3.5+: |
| 47 |
> > |
| 48 |
> > $ python3.5 -O -c 'import pycparser; print(pycparser.__cached__)' |
| 49 |
> > /usr/lib64/python3.5/site-packages/pycparser/__pycache__/__init__.cpython-35.opt-1.pyc |
| 50 |
> > |
| 51 |
> > > Are we sure that it's worth it to load all of the __doc__ strings into |
| 52 |
> > > memory, given that we have alternative implementations for everything |
| 53 |
> > > that pycrypto provides? |
| 54 |
> > |
| 55 |
> > I dare say that if -O can cause completely random total breakage, then |
| 56 |
> > we shouldn't risk doing that for the sake of some minor memory savings. |
| 57 |
> > It's not a case of 'support for pycryptodome' vs '1M memory saving'. |
| 58 |
> > It's a case of 'loading random module can wreak total havoc in Portage'. |
| 59 |
> |
| 60 |
> Seems reasonable. Please merge. |
| 61 |
|
| 62 |
Merged, thanks. |
| 63 |
-- |
| 64 |
Best regards, |
| 65 |
Michał Górny |
Archives