[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-08-29 - 2014-09-05)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4640 ( +2)
closed 29471 (+40)
total 34111 (+42)
Open issues with patches: 2191
Issues opened (29)
==
#16037: httplib: header parsing is unlimited
http://bugs.python.org/issue16037 reopened by Arfrever
#22301: smtplib.SMTP.starttls' documentation is just confusing
http://bugs.python.org/issue22301 opened by maker
#22302: Windows os.path.isabs UNC path bug
http://bugs.python.org/issue22302 opened by akima
#22303: Write better test for SSLContext.load_verify_locations
http://bugs.python.org/issue22303 opened by pitrou
#22305: Documentation on deepcopy's problems is misleading
http://bugs.python.org/issue22305 opened by shlsh
#22308: add {implementation} to sysconfig.py
http://bugs.python.org/issue22308 opened by mattip
#22309: distutils/spawn.py handle fork() not implemented.
http://bugs.python.org/issue22309 opened by John.Malmberg
#22310: Report actual EOF character instead of assuming Ctrl-D
http://bugs.python.org/issue22310 opened by John.Malmberg
#22313: Make PYLONG_BITS_IN_DIGIT always available to non-core extensi
http://bugs.python.org/issue22313 opened by scoder
#22314: pydoc.py: TypeError with a $LINES defined to anything
http://bugs.python.org/issue22314 opened by arigo
#22317: action argument is not documented in argparse add_subparser()
http://bugs.python.org/issue22317 opened by Ubik
#22319: mailbox.MH chokes on directories without .mh_sequences
http://bugs.python.org/issue22319 opened by gumnos
#22323: Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString(
http://bugs.python.org/issue22323 opened by haypo
#22324: Use PyUnicode_AsWideCharString() instead of PyUnicode_AsUnicod
http://bugs.python.org/issue22324 opened by haypo
#22326: tempfile.TemporaryFile fails on NFS v4 filesystems
http://bugs.python.org/issue22326 opened by drosera
#22327: test_gdb failures on Ubuntu 14.10
http://bugs.python.org/issue22327 opened by barry
#22329: Windows installer can't recover partially installed state
http://bugs.python.org/issue22329 opened by LlelanD
#22330: PyOS_mystricmp is broken
http://bugs.python.org/issue22330 opened by kakkoko
#22331: test_io.test_interrupted_write_text() hangs on the buildbot Fr
http://bugs.python.org/issue22331 opened by haypo
#22332: test_multiprocessing_main_handling fail on buildbot "x86 FreeB
http://bugs.python.org/issue22332 opened by haypo
#22333: test_threaded_import.test_parallel_meta_path() failed on x86 W
http://bugs.python.org/issue22333 opened by haypo
#22334: test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x" buildbot
http://bugs.python.org/issue22334 opened by haypo
#22335: Python 3: Segfault instead of MemoryError when bytearray too b
http://bugs.python.org/issue22335 opened by swanson
#22336: _tkinter should use Python PyMem_Malloc() instead of Tcl ckall
http://bugs.python.org/issue22336 opened by haypo
#22338: test_json crash on memory allocation failure
http://bugs.python.org/issue22338 opened by haypo
#22339: Incorrect behavior when subclassing enum.Enum
http://bugs.python.org/issue22339 opened by Walkman
#22340: Fix Python 3 warnings in Python 2 tests
http://bugs.python.org/issue22340 opened by haypo
#22341: Python 3 crc32 documentation clarifications
http://bugs.python.org/issue22341 opened by vadmium
#22342: Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator
http://bugs.python.org/issue22342 opened by Gael.Robin
Most recent 15 issues with no replies (15)
==
#22342: Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator
http://bugs.python.org/issue22342
#22341: Python 3 crc32 documentation clarifications
http://bugs.python.org/issue22341
#22338: test_json crash on memory allocation failure
http://bugs.python.org/issue22338
#22327: test_gdb failures on Ubuntu 14.10
http://bugs.python.org/issue22327
#22317: action argument is not documented in argparse add_subparser()
http://bugs.python.org/issue22317
#22314: pydoc.py: TypeError with a $LINES defined to anything
http://bugs.python.org/issue22314
#22313: Make PYLONG_BITS_IN_DIGIT always available to non-core extensi
http://bugs.python.org/issue22313
#22303: Write better test for SSLContext.load_verify_locations
http://bugs.python.org/issue22303
#22300: PEP 446 What's New Updates for 2.7.9
http://bugs.python.org/issue22300
#22294: 2to3 consuming_calls: len, min, max, zip, map, reduce, filter
http://bugs.python.org/issue22294
#22289: support.transient_internet() doesn't catch timeout on FTP test
http://bugs.python.org/issue22289
#22286: Allow backslashreplace error handler to be used on input
http://bugs.python.org/issue22286
#22268: mrohasattr and mrogetattr
http://bugs.python.org/issue22268
#22255: Multiprocessing fre
Re: [Python-Dev] cpython and parallel make
>> > Would people be interested in having a parallel version? >> >> See http://bugs.python.org/issue5309 > > Cool! I'll look into this. The patch there works well for me. I've made one small update, and submitted the new version in the bug tracker. Regarding the other build problem, I might have found some hint: - Parser/pgen.o ends up in both the PARSER_OBJS and PGENOBJS variables in the Makefile - PARSER_OBJS is depended upon in a few places, hence it could be that make starts to build Parser/pgen.o - PGENOBJS is built when building PGEN, which happens *in a different make that is called recursively* I think the culprit is the rule for GRAMMAR_H which calls make recursively. Is there a reason that GRAMMAR_H has to generate PGEN like this? Couldn't it just depend on PGEN? Cheers, Jonas ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython and parallel make
> > Would people be interested in having a parallel version? > > See http://bugs.python.org/issue5309 Cool! I'll look into this. Just as I was thinking that the parallel build problems are solved, the issue surfaced again. I've attached a complete, unmodified log to this mail. Some notes: - asap-clang is a wrapper around Clang that I use for a research project. It should behave the same way as Clang in this case. If anything, it might be less threadsafe. - commands such as configure_and_build_python are from a shell script that invokes configure, make, etc. - This is running on Ubuntu 14.04 with Clang 3.5 and GNU Make 3.81, and a fresh checkout of Python 3.4 - I see two compiler invocations for Parser/pgen.c . Not sure why this happens. It seems to cause the pgen.o file to be empty or truncated. Any ideas? Cheers, Jonas 16:30:06 + mkdir cpython-asan-build 16:30:06 + cd cpython-asan-build 16:30:06 + asap-clang -asap-init 16:30:06 # Initialized ASAP state in /home/jenkins/workspace/asap-benchmarks/python34-experiments/cpython-asan-build/asap_state. Now run: 16:30:06 export ASAP_STATE_PATH="/home/jenkins/workspace/asap-benchmarks/python34-experiments/cpython-asan-build/asap_state" 16:30:06 ++ pwd 16:30:06 + export ASAP_STATE_PATH=/home/jenkins/workspace/asap-benchmarks/python34-experiments/cpython-asan-build/asap_state 16:30:06 + ASAP_STATE_PATH=/home/jenkins/workspace/asap-benchmarks/python34-experiments/cpython-asan-build/asap_state 16:30:06 + configure_and_build_python '-O3 -fsanitize=address' -fsanitize=address 16:30:06 + configure_python '-O3 -fsanitize=address' -fsanitize=address 16:30:06 + cflags='-O3 -fsanitize=address' 16:30:06 + ldflags=-fsanitize=address 16:30:06 + mkdir build 16:30:06 + cd build 16:30:06 ++ which asap-clang 16:30:06 ++ which asap-clang++ 16:30:06 ++ which asap-ar 16:30:06 ++ which asap-ranlib 16:30:06 + ../../cpython/configure --without-pymalloc --disable-shared --disable-ipv6 CC=/home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang CXX=/home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang++ AR=/home/jenkins/workspace/asap-build/llvm-build/bin/asap-ar RANLIB=/home/jenkins/workspace/asap-build/llvm-build/bin/asap-ranlib 'CFLAGS=-O3 -fsanitize=address' LDFLAGS=-fsanitize=address 16:30:07 checking for hg... found 16:30:07 checking build system type... x86_64-unknown-linux-gnu 16:30:07 checking host system type... x86_64-unknown-linux-gnu 16:30:07 checking for --enable-universalsdk... no 16:30:07 checking for --with-universal-archs... no 16:30:07 checking MACHDEP... linux 16:30:07 checking for --without-gcc... no 16:30:07 checking for gcc... /home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang 16:30:07 checking whether the C compiler works... yes 16:30:08 checking for C compiler default output file name... a.out 16:30:08 checking for suffix of executables... 16:30:08 checking whether we are cross compiling... no 16:30:08 checking for suffix of object files... o 16:30:08 checking whether we are using the GNU C compiler... yes 16:30:08 checking whether /home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang accepts -g... yes 16:30:08 checking for /home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang option to accept ISO C89... none needed 16:30:09 checking for --with-cxx-main=... no 16:30:09 checking for -Wl,--no-as-needed... yes 16:30:09 checking how to run the C preprocessor... /home/jenkins/workspace/asap-build/llvm-build/bin/asap-clang -E 16:30:09 checking for grep that handles long lines and -e... /bin/grep 16:30:09 checking for egrep... /bin/grep -E 16:30:09 checking for ANSI C header files... yes 16:30:10 checking for sys/types.h... yes 16:30:11 checking for sys/stat.h... yes 16:30:11 checking for stdlib.h... yes 16:30:11 checking for string.h... yes 16:30:11 checking for memory.h... yes 16:30:12 checking for strings.h... yes 16:30:12 checking for inttypes.h... yes 16:30:12 checking for stdint.h... yes 16:30:12 checking for unistd.h... yes 16:30:13 checking minix/config.h usability... no 16:30:13 checking minix/config.h presence... no 16:30:13 checking for minix/config.h... no 16:30:13 checking whether it is safe to define __EXTENSIONS__... yes 16:30:13 checking for --with-suffix... 16:30:13 checking for case-insensitive build directory... no 16:30:14 checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a 16:30:14 checking LINKCC... $(PURIFY) $(MAINCC) 16:30:14 checking for GNU ld... yes 16:30:14 checking for inline... inline 16:30:14 checking for --enable-shared... no 16:30:14 checking for --enable-profiling... no 16:30:14 checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a 16:30:14 checking for ranlib... /home/jenkins/workspace/asap-build/llvm-build/bin/asap-ranlib 16:30:14 checking for readelf... readelf 16:30:14 checking for python3.4... python3.4 16:30:14 checking for a BSD-compatible install... /usr/bin/install -c 16:30:14 checking for a thread-safe mkdir -p... /bin/mkdir -p 16:30:14 checking for --with-pydebug... n
Re: [Python-Dev] cpython and parallel make
Hi again, the attached Makefile patch seems to fix the parallel build problems. Is there a chance of getting this into trunk? Should I open an issue or send the patch somewhere else? Cheers, Jonas On Fri, Sep 5, 2014 at 12:15 PM, Jonas Wagner wrote: >>> > Would people be interested in having a parallel version? >>> >>> See http://bugs.python.org/issue5309 >> >> Cool! I'll look into this. > > The patch there works well for me. I've made one small update, and > submitted the new version in the bug tracker. > > Regarding the other build problem, I might have found some hint: > - Parser/pgen.o ends up in both the PARSER_OBJS and PGENOBJS variables > in the Makefile > - PARSER_OBJS is depended upon in a few places, hence it could be that > make starts to build Parser/pgen.o > - PGENOBJS is built when building PGEN, which happens *in a different > make that is called recursively* > > I think the culprit is the rule for GRAMMAR_H which calls make > recursively. Is there a reason that GRAMMAR_H has to generate PGEN > like this? Couldn't it just depend on PGEN? > > Cheers, > Jonas diff -r 13cd8ea4cafe Makefile.pre.in --- a/Makefile.pre.in Fri Sep 05 11:00:56 2014 +0300 +++ b/Makefile.pre.in Fri Sep 05 14:24:30 2014 +0200 @@ -679,11 +679,12 @@ # Importlib +Modules/_freeze_importlib.o: Modules/_freeze_importlib.c + Modules/_freeze_importlib: Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LINKCC) $(PY_LDFLAGS) -o $@ Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) -Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py Modules/_freeze_importlib.c - $(MAKE) Modules/_freeze_importlib +Python/importlib.h: $(srcdir)/Lib/importlib/_bootstrap.py Modules/_freeze_importlib ./Modules/_freeze_importlib \ $(srcdir)/Lib/importlib/_bootstrap.py Python/importlib.h @@ -745,15 +746,13 @@ $(IO_OBJS): $(IO_H) -$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGENSRCS) +$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN) @$(MKDIR_P) Include - $(MAKE) $(PGEN) $(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) -$(GRAMMAR_C): $(GRAMMAR_H) $(GRAMMAR_INPUT) $(PGENSRCS) - $(MAKE) $(GRAMMAR_H) +$(GRAMMAR_C): $(GRAMMAR_H) touch $(GRAMMAR_C) -$(PGEN): $(PGENOBJS) +$(PGEN): $(PGENOBJS) $(CC) $(OPT) $(PY_LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) Parser/grammar.o: $(srcdir)/Parser/grammar.c \ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython and parallel make
Open an issue on bugs.python.org and attach the patch there (it should also ask you so sign the contributor agreement, but if not then please also sign that). On Fri Sep 05 2014 at 12:52:45 PM Jonas Wagner wrote: > Hi again, > > the attached Makefile patch seems to fix the parallel build problems. > > Is there a chance of getting this into trunk? Should I open an issue > or send the patch somewhere else? > > Cheers, > Jonas > > On Fri, Sep 5, 2014 at 12:15 PM, Jonas Wagner > wrote: > >>> > Would people be interested in having a parallel version? > >>> > >>> See http://bugs.python.org/issue5309 > >> > >> Cool! I'll look into this. > > > > The patch there works well for me. I've made one small update, and > > submitted the new version in the bug tracker. > > > > Regarding the other build problem, I might have found some hint: > > - Parser/pgen.o ends up in both the PARSER_OBJS and PGENOBJS variables > > in the Makefile > > - PARSER_OBJS is depended upon in a few places, hence it could be that > > make starts to build Parser/pgen.o > > - PGENOBJS is built when building PGEN, which happens *in a different > > make that is called recursively* > > > > I think the culprit is the rule for GRAMMAR_H which calls make > > recursively. Is there a reason that GRAMMAR_H has to generate PGEN > > like this? Couldn't it just depend on PGEN? > > > > Cheers, > > Jonas > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
