[issue1109963] bdist_wininst ignores build_lib from build command
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: The offending code appears to have been introduced in r33090 and tweaked in r37025, which both originated from Mark Hammond. From the comments, there seems to be no reason why the build_lib override should apply when the target version is specifically different from the version being used to build the extension, hence I've attached a patch which applies the override only when the versions are different (for both bdist_wininst and bdist_msi). This doesn't solve the problem that exists when the target and build versions are different and build_lib has been overridden in setup.py (as I understand is the case with cx_Oracle). I've added Mark to the nosy list in the hope he might, as originator of the problematic changes, be able to provide some insight. -- keywords: +patch nosy: +aimacintyre, mhammond Added file: http://bugs.python.org/file13748/python_issue_1109963.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1109963 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1533520] Allow thread(ing) tests to pass without setting stack size
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: Pretty much all the test structure in the patch has made it through the re-write to unittest, so closed as out of date. -- resolution: - out of date status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1533520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3868] patch for review: OS/2 EMX port fixes for 2.6
Changes by Andrew I MacIntyre aimacint...@users.sourceforge.net: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5722] settimer / gettimer functionality on FreeBSD 6.3 (not 7.x)
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: I've just built (using ./configure; make) 3.1a on FreeBSD 6.4 amd64. libpthread is used by the resulting binary, not libc_r, according to ldd. I would expect then that explicit action is required to use libc_r, and given that FreeBSD people have indicated that it is deprecated and no fixes are likely to be made, I would suggest documenting this as a don't do that (ie use -lc_r) and close this as won't fix. The README file in the root of the source tree would seem an appropriate place for such documentation, though I note that there appears to be a lot of out of date information in there already... -- nosy: +aimacintyre ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: Antoine, in my testing the loss of the HAS_ARG() optimisation in my patch appears to have negligible cost on i386, but starts to look significant on amd64. On an Intel E8200 cpu running FreeBSD 7.1 amd64, with gcc 7.2.1 and the 3.1a2 sources, the computed goto version is ~8% faster (average time of all rounds) for pybench (with warp factor set to 3 rather than the default 10, to get the round time up over 10s) than without computed gotos. With my patch applied, the computed goto version is ~5.5% faster than without computed gotos by the same measure. On this platform, Pystone rates at ~86k (no computed gotos), ~85k (computed gotos) and ~82k (computed gotos + my patch). For comparison, this machine running Windows XP (32 bit) with the python.org builds rates ~92k pystones for 2.6.1 and ~81k for 3.1a2. Pybench isn't distributed in the MSI installers :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4753] Faster opcode dispatch on gcc
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment: Out of interest, the attached patch against the py3k branch at r70516 cleans up the threaded code changes a little: - gets rid of TARGET_WITH_IMPL macro; - TARGET(op) is followed by a colon, so that it looks like a label (for editors that make use of that). On my systems (all older AMD with old versions of gcc), this patch has performance slightly better than SVN r70516, and performance is usually very close to the NO_COMPUTED_GOTOS build. -- nosy: +aimacintyre Added file: http://bugs.python.org/file13392/ceval.c.threadcode-tidyup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I believe this issue ties into the underlying problem FreeBSD 6.x upto and including 6.3R have with fork() in a threaded application - see the 6.3R errata notice referenced in issue3864. The issue should be fixed in FreeBSD 6.4 (currently in beta), but it would be nice to get the patch in to Python 2.6 and Python 3.0 (not sure about 2.5) just so that running the test doesn't hang on earlier 6.x releases. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: The checked in change has the planned effect on FreeBSD 6.3 i386. I can't check on my 7.0 amd64 box as I can't quickly put a current source tree on it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3862] test_array fails on FreeBSD7 amd64
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Yes, the bleeding obvious became so after some sleep. Committed to trunk as r66708 with the extra fix and a more abbreviated failure message, which I hope is still semantically the same as Mark's suggested text. Will forward port as appropriate to py3k. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: The tests are passing on FreeBSD 7.0 (only checked amd64 at this point). I came across a reference to an errata notice for FreeBSD 6.x which appears pertinent: http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc As I read the above notice, the underlying issue is a FreeBSD bug which will be fixed in FreeBSD 6.4 (expected to be released in the next couple of months. On this basis, I suggest closing this as Won't fix. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I've done some more digging into this for the FreeBSD case. FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it should be fully functional. (see http://www.freebsd.org/cgi/man.cgi?query=sem_openapropos=0sektion=0manpath=FreeBSD+6.3-RELEASEformat=html) There is a caveat on the length of the name, which I think could trigger if the counter variable passed into SEM_CREATE() is . But as that variable seems like it can only ever be 0 (not sure this is intended!) this shouldn't happen as it stands. If I change HAVE_SEM_OPEN to 1 in setup.py, the _multiprocessing module builds, but test_multiprocessing provokes a core dump in both cases. The backtrace (on 6.3 i386) looks like: #0 0x2820ef17 in ksem_open () from /lib/libc.so.6 #1 0x2820592c in sem_open () from /lib/libc.so.6 #2 0x284494a0 in semlock_new (type=0x2844b380, args=0x836443c, kwds=0x0) at /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:439 #3 0x0809e710 in type_call (type=0x2844b380, args=0x836443c, kwds=0x0) at Objects/typeobject.c:731 #4 0x0806042a in PyObject_Call (func=0x2844b380, arg=0x836443c, kw=0x0) at Objects/abstract.c:2487 #5 0x080cc367 in PyEval_EvalFrameEx (f=0x84dd00c, throwflag=0) at Python/ceval.c:3890 #6 0x080cf9ac in PyEval_EvalCodeEx (co=0x8478800, globals=0x4e, locals=0xa00, args=0x819b02c, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #7 0x08123f84 in function_call (func=0x8486ca4, arg=0x82e107c, kw=0x0) at Objects/funcobject.c:524 #8 0x0806042a in PyObject_Call (func=0x8486ca4, arg=0x82e107c, kw=0x0) at Objects/abstract.c:2487 #9 0x08069c15 in instancemethod_call (func=0x4e, arg=0x82e107c, kw=0x0) at Objects/classobject.c:2579 #10 0x0806042a in PyObject_Call (func=0x84857ac, arg=0x82e107c, kw=0x0) at Objects/abstract.c:2487 #11 0x080cc367 in PyEval_EvalFrameEx (f=0x826140c, throwflag=0) at Python/ceval.c:3890 ---Type return to continue, or q return to quit--- On 7.0 amd64, the top of the backtrace scrolls off screen so I can't get the start of the trace (X not installed...). To try and remove threads from the equation, due to FreeBSD 6.3 having an issue with fork() in a threaded build (see issue3864 for more info), I configured without threads (ie ./configure --without-threads) and the _multiprocessing module fails to build: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -I/home/andymac/build/python-svn/trunk-r66550/./Include -I. -IInclude -I./Include -I/usr/local/include -I/home/andymac/build/python-svn/trunk-r66550/Include -I/home/andymac/build/python-svn/trunk-r66550 -c /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c -o build/temp.freebsd-6.3-RELEASE-i386-2.6/home/andymac/build/python-svn/trunk-r66550/Modules/_mult iprocessing/semaphore.o /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c: In function `semlock_acquire': /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: `_save' undeclared (first use in this function) /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: (Each undeclared identifier is reported only once /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: for each function it appears in.) It appears that some support is there for a single threaded build, but is incomplete (there's a similar problem in socket_connections.c, but the module build bails before then). If its not to be supported on single threaded builds (which would be a big shame in my opinion!) then the code should make this explicit, otherwise the single threaded build case needs to be fixed. I'm still trying to understand the core dump in the multithreaded build - unfortunately I'm not terribly familiar with gdb or with debugging from cores (and the actual failure appears to be triggering in the C library for which I currently don't appear to have symbols...) Any suggests on how/where to dig further on this? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Oops - meant to add that the actual reported cause of the core dump is Bad system call. Also, the OpenBSD man pages make clear that shared semaphores aren't supported and sem_open() doesn't exist: http://www.openbsd.org/cgi-bin/man.cgi?query=sem_openapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've had a chance to do some testing and it _is_ related to the itimer
tests (in test_wait4).
This is with r66550:
$ ./python -E -tt ./Lib/test/regrtest.py -l -v test_wait4 test_signal
test_wait4
test_wait (test.test_wait4.Wait4Test) ... ok
--
Ran 1 test in 5.007s
OK
test_signal
test_getsignal (test.test_signal.BasicSignalTests) ... ok
test_out_of_range_signal_number_raises_error
(test.test_signal.BasicSignalTests) ... ok
test_setting_signal_handler_to_none_raises_error
(test.test_signal.BasicSignalTests) ... ok
test_main (test.test_signal.InterProcessSignalTests) ... FAIL
test_wakeup_fd_during (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_early (test.test_signal.WakeupSignalTests) ... ok
test_siginterrupt_off (test.test_signal.SiginterruptTest) ... ok
test_siginterrupt_on (test.test_signal.SiginterruptTest) ... ok
test_without_siginterrupt (test.test_signal.SiginterruptTest) ... ok
test_itimer_exc (test.test_signal.ItimerTest) ... ok
test_itimer_prof (test.test_signal.ItimerTest) ...
Running only test_signal:
$ ./python -E -tt ./Lib/test/regrtest.py -l -v test_signal
test_signal
test_getsignal (test.test_signal.BasicSignalTests) ... ok
test_out_of_range_signal_number_raises_error
(test.test_signal.BasicSignalTests)
... ok
test_setting_signal_handler_to_none_raises_error
(test.test_signal.BasicSignalTe
sts) ... ok
test_main (test.test_signal.InterProcessSignalTests) ... ok
test_wakeup_fd_during (test.test_signal.WakeupSignalTests) ... ok
test_wakeup_fd_early (test.test_signal.WakeupSignalTests) ... ok
test_siginterrupt_off (test.test_signal.SiginterruptTest) ... ok
test_siginterrupt_on (test.test_signal.SiginterruptTest) ... ok
test_without_siginterrupt (test.test_signal.SiginterruptTest) ... ok
test_itimer_exc (test.test_signal.ItimerTest) ... ok
test_itimer_prof (test.test_signal.ItimerTest) ... ('SIGPROF handler
invoked', (
27, frame object at 0x83c860c))
ok
test_itimer_real (test.test_signal.ItimerTest) ...
call pause()...
('SIGALRM handler invoked', (14, frame object at 0x83c8c0c))
ok
test_itimer_virtual (test.test_signal.ItimerTest) ... ('SIGVTALRM
handler invoke
d', (26, frame object at 0x83c920c))
('SIGVTALRM handler invoked', (26, frame object at 0x83c920c))
('SIGVTALRM handler invoked', (26, frame object at 0x83c920c))
last SIGVTALRM handler call
('SIGVTALRM handler invoked', (26, frame object at 0x83c920c))
ok
--
Ran 13 tests in 6.534s
OK
1 test OK.
Noting the interprocess signal test failure, I tried deactivating it and
the itimer tests still go off into the never never (using all available
CPU cycles too).
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3864
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Oops - the itimer tests are in test_signal, not test_wait4. test_wait4 just triggers the problems in test_signal (both the itimer problems and the interprocess signal test failure). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: After perusing test_wait4, I tried substituting test_fork1 for test_wait4 and got the same behaviour from test_signal. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I compiled the C test case from issue 2240:
$ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -o test_2240
test_2240.c
{lifted as many gcc options off the standard Python compile as possible}
$ ldd test_2240
test_2240:
libpthread.so.2 = /lib/libpthread.so.2 (0x2807a000)
libc.so.6 = /lib/libc.so.6 (0x2809f000)
$ ./test_2240
0
1 0
deactive ITIMER_PROF
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3864
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Spelunking with test_fork1, it seems that the interprocess signal test failure is due to the HUP signal not being delivered from the subprocess to the parent (line 99 of test_signal.py: self.assertTrue(self.a_called). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: From the problematic test run log: ... test_main (test.test_signal.InterProcessSignalTests) ... FAIL ... I should be using the full name, sorry. This failure seems unrelated to the itimer problem though (which is in itimer_test_prof). If I deactivate it, the itimer tests still goes into the never never. Both however are reliably triggered by running test_fork1 or test_wait4 (which uses the same machinery as test_fork1) before test_signal. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I should be more specific: itimer_test_prof (test.test_signal.ItimerTest) appears to go into an infinite loop when run after test_fork1 or test_wait4 have been run. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3868] patch for review: OS/2 EMX port fixes for 2.6
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Committed in revs 66552, 66553 and 66554. I've blocked r66554 from py3k as other changes are needed for OS/2 (r66555) I've merged r66552 and r66553 into py3k as they apply cleanly (r66556). Thanks for the review Amaury. -- assignee: - aimacintyre priority: - normal resolution: - accepted status: open - pending versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3862] test_array fails on FreeBSD7 amd64
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Mark, your patch will probably get the test to pass, but the underlying reason the test is failing appears to be unexpected behaviour of the platform malloc(). FreeBSD 7.0 introduced a new malloc() implementation that relies on mmap() and this is behaving differently to the malloc() implementation in FreeBSD 6.3 which relied on sbrk(). I have posted a query about the new malloc()'s behaviour to a FreeBSD forum and will report what I find out. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: It doesn't appear to me to be related to issue 2240, as my build linked against libpthread: $ ldd ./python ./python: libutil.so.5 = /lib/libutil.so.5 (0x28187000) libm.so.4 = /lib/libm.so.4 (0x28193000) libpthread.so.2 = /lib/libpthread.so.2 (0x281a9000) libc.so.6 = /lib/libc.so.6 (0x281ce000) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I've briefly got a FreeBSD 7.0 amd64 setup available, and test_threading passes in this environment. Short term fix I'd suggest is to only disable this part of the test for FreeBSD 6.x and earlier (ie platforms freebsd4, freebsd5, freebsd6). I also checked my OS/2 EMX build and wasn't surprised to see it fail on the same part of test_threading - fork() on OS/2 EMX is fragile enough without threads in the mix. If a disabler is added for FreeBSD as above, 'os2emx' should be in the same list. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3862] test_array fails on FreeBSD7 amd64
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I've temporarily got a 7.0 amd64 system running and can confirm what you see. I checked out the 2.5.2 port patches you mentioned, but all the ones that seemed related are already in the 2.6rc1 sources. On a hunch, I used ulimit -v is used to set a process virtual memory size limit, and the test completed satisfactorily (I set it to 1048756, ie 1GB). I'm as yet none the wiser as to what to do with this info... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3862] test_array fails on FreeBSD7 amd64
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: On FreeBSD 7.0 i386, test_array passes without ulimit -v needing to be set (ie its still the default unlimited. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: test_threading also passes on FreeBSD 7.0 i386. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I've attached a simple patch which deactivates test_3_join_in_forked_from_thread on FreeBSD 6.x and earlier, and also OS/2 EMX. With this patch, test_threading completes but... $ ./python -E -tt Lib/test/regrtest.py test_threading test_threading 1 test OK. Unhandled exception in thread started by Error in sys.excepthook: Original exception was: -- keywords: +patch Added file: http://bugs.python.org/file11495/test_threading_fbsd6.py.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3868] patch for review: OS/2 EMX port fixes for 2.6
Changes by Andrew I MacIntyre [EMAIL PROTECTED]: -- components: Build, Interpreter Core, Library (Lib), Tests files: build_os2emx.patch keywords: patch, patch nosy: aimacintyre severity: normal status: open title: patch for review: OS/2 EMX port fixes for 2.6 versions: Python 2.6 Added file: http://bugs.python.org/file11487/build_os2emx.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3868] patch for review: OS/2 EMX port fixes for 2.6
New submission from Andrew I MacIntyre [EMAIL PROTECTED]: The 2 attached patch files are patches required for the OS/2 EMX port to build and function: - build_os2emx.patch - updates to the Makefile and config files in PC/os2emx; - source_os2emx.patch - updates to various core/library/test files. = Include/pystrcmp.h (OS/2 is like Windows, with the same C lib routines) = Lib/test/test_io.py (OS/2 is like Windows again) = Objects/floatobject.c (should use macro'd symbols not direct) = Python/pymath.c (any platform without HAVE_LOG1P should have DBL_EPSILON in float.h) For review so that the fixes can be rolled into 2.6 final. Added file: http://bugs.python.org/file11488/source_os2emx.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: 2.6rc1 shows the same failure traceback on FreeBSD 6.3, which is covered by a section of setup.py the same as Damien added for OpenBSD. -- nosy: +aimacintyre ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3862] test_array fails on FreeBSD7 amd64
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: 2.6rc1 test_array passes on FreeBSD 6.3 i386. I don't have a 7.0 box (either i386 or amd64) accessible at the moment to cross check. Can you run the test on its own in verbose mode to get a bit more of an idea where its blowing up? - ie: [EMAIL PROTECTED] ./python -E -tt Lib/test/regrtest.py -v test_array from the build directory. -- nosy: +aimacintyre ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3862 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3863] 2.6rc1: test_threading hangs on FreeBSD 6.3 i386
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I should add that this is a regression of the trunk, as I built and tested the trunk from an SVN checkout (r63892) in early June and didn't encounter this issue. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Changes by Andrew I MacIntyre [EMAIL PROTECTED]: -- versions: +Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3029] free list management - list, dict, set
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Freelist clearing functions for int and float were added by Christian, and made available to Python code via a function in the sys module. I don't know who added the freelist clearing functions for the class, frame, method, tuple and unicode objects, but they are called by gc.collect(). Because the freelist implementations are all static to the relevant type source files, functions within each object source file seem a reasonable way of implementing the required functionality. I don't see the need for them to be part of the public API, but I framed this patch to fit in with what's already in place. It is likely that the functionality of this patch is of minor value, and can thus be rejected. Indeed, I experimented with ripping out all freelists and making sure that all types used PyMalloc, and the resulting interpreter is about 6-8% slower on a pybench run (FreeBSD 7.0, gcc 4.2.1, 6% slower on 32bit, 8% slower on 64bit, 64bit is ~15% faster than 32bit in either case) than the trunk (r63501). Individual micro-benchmarks in pybench show 15-30% variations between the freelist no freelist, but this doesn't seem to significantly affect the running of the whole benchmark. Issue 2862 is more important IMO, as the current situation has 2 different approaches to accessing freelist management, where I believe there should only be 1. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3029] free list management - list, dict, set
New submission from Andrew I MacIntyre [EMAIL PROTECTED]: The attached patch adds free list clearing routines for the list, dict set objects. These objects are the only ones with free lists that don't already have some form of free list management API. This patch complements the patch in issue 2862. -- assignee: christian.heimes components: Interpreter Core files: list_dict_set_clearfreelist.patch keywords: patch, patch messages: 67636 nosy: aimacintyre, christian.heimes priority: high severity: normal status: open title: free list management - list, dict, set type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10503/list_dict_set_clearfreelist.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2862] cleanup of freelist management
New submission from Andrew I MacIntyre [EMAIL PROTECTED]: In r60567, support for compacting the int float freelists was added with a function in the sys module to call the compaction routines. Since then, other freelist clearing routines have been added to other types and are called from the collect() function in the gc module. The attached patch harmonises the in/float freelist compaction with the other freelist clearing mechanisms. It does away with the function in the sys module in favour of running the freelist clearing from gc.collect(). The signatures of the type specific freelist clearing routines have been brought into line with the other type freelist clearing routines, with the exception that they return the number of items _not_ free()ed, rather than the number of items free()ed. I took this approach to try and highlight the fact the current int/float freelist implementations don't use pymalloc and not all items will always be free()ed when the routine is called. This return is ignored when called from gc.collect() in any case. The patch includes doc updates and test updates to reflect the changes. It has been tested on FreeBSD 6.3, surviving a default test run with no unusual test failures as far as I can tell. It is not otherwise rigorously tested. The patch is against a trunk checkout that seems to be at r63156. Ideally this patch, or similar modifications, should be applied before the feature freeze for 2.6, so that freelist management is rationalised to one way to do it. -- assignee: christian.heimes components: Documentation, Interpreter Core, Tests files: freelist_mgt_cleanup.patch keywords: patch, patch messages: 66858 nosy: aimacintyre, christian.heimes priority: high severity: normal status: open title: cleanup of freelist management type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10331/freelist_mgt_cleanup.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2862 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2039] Pymalloc patch for int and float objects
Andrew I MacIntyre added the comment: As noted in a posting to python-dev, I've re-evaluated my test methodology. The results are as follows, with details of the PyBench runs in the pybench_summary.txt attachment: -- testtrunkno-freelists LIFO(500i,100f) case 1case 2 case 1case 2 case 1 case 2 -- pystone 26500 26100 27000 25600 2700026600 int 1 7.27us9.09us 6.69us20.4us 6.64us 9.25us int 2 10.4us9.48us 20.9us20.9us 10.5us 9.69us int 3 381us 360us 792us 813us 805us780us int 4 393us 373us 829us 834us 844us799us float 1 1.14ms1.1ms 1.2ms 1.2ms 1.2ms1.27ms float 2 773us 831us 1.05ms908us 865us967us float 3 733us 759us 970us 825us 804us906us float 4 74.6us76.9us 100us 83.7us 77.6us 86.9us float 5 7.88ms8.09ms 10.7ms8.93ms 8.46ms 9.43ms pybench 16716ms 1ms16674ms 16612ms16612ms 16611ms script a30.7s 30.6s 33.0s 33.0s 32.3s32.6s script b41.7s 40.6s 42.1s 39.4s 40.5s41.8s -- case: 1=std, 2=no small ints test details pystone: average of 3 runs int 1: ./python -m timeit -s range(1000) range(250) int 2: ./python -m timeit -s range(1000) range(257,507) int 3: ./python -m timeit -s range(1) range(1) int 4: ./python -m timeit -s range(11000) range(257,10507) float 1: ./python -m timeit -s [float(x) for x in range(1000)] \ [float(x) for x in range(1000)] float 2: ./python -m timeit -s map(float, range(1000)) map(float, range(1000)) float 3: ./python -m timeit -s t = range(1000) map(float, t) float 4: ./python -m timeit -s t = range(100) map(float, t) float 5: ./python -m timeit -s t = range(1) map(float, t) pybench: average runtime per round of ./python Tools/pybench/pybench.py -f logfile script a: code import time def b(time_now=time.clock): limit_val = 200 d = [None] * limit_val start_time = time_now() for j in xrange(25): for i in xrange(limit_val): d[i] = i for i in d: d[i] = None return time_now() - start_time if __name__ == '__main__': print 'elapsed: %s s' % b() /code script b: code import time def b(time_now=time.clock): limit_val = 100 f = [None] * limit_val d = range(limit_val) start_time = time_now() for j in xrange(25): for i in d: f[i] = float(i) for i in d: f[i] = None return time_now() - start_time if __name__ == '__main__': print 'elapsed: %s s' % b() /code Added file: http://bugs.python.org/file9469/pybench_summary.txt __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2039 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2039] Pymalloc patch for int and float objects
Andrew I MacIntyre added the comment: My conclusions from the testing I've just reported: - there are some contradictory results which make little (obvious) sense, but the testing has been repeated a number of times and nearly all tests repeat to with 1%; - leave the int freelist as is, but move the compaction into gc.collect() as suggested by tiran in a python-dev posting; - keep the small int cache (it may profitably be increased to cover a wider range of ints, perhaps -256..1024?? - more testing required); - the float freelist and float LIFO, while being attractive in micro-benchmarks, are not useful enough to keep in large scale usage. This is especially the case when you consider that floats are much less prevalent than ints in a wide range of Python programs. Serious float users gravitate to Numpy and other extensions in most cases, and the simpler memory profile has its own attractions. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2039 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2039] Pymalloc patch for int and float objects
Andrew I MacIntyre added the comment: I've realised I could have included tests for a build with the int freelist but without the float freelist, to justify my conclusions. The short version: the script tests are almost identical to the baseline result most of the other results are between the no-freelist results and the freelist/LIFO results. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2039 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2039] Pymalloc patch for int and float objects
Andrew I MacIntyre added the comment: As indicated in a python-dev posting, I'm adding my experimental grade patches removing the freelists from ints and floats. Subject to testing on other platforms (I've only tested on FreeBSD 6.1 and OS/2), I suggest that the float case should be seriously considered, as there seems little advantage to the complexity of the freelist, with better memory utilisation likely to flow from relying on PyMalloc on top of being faster than the current freelist implementation (for reasons unknown; the version in tiran's patch performs similar to the no-freelist patch). The int freelist is enough ahead in performance (although only 3-5%) to justify ignoring the better memory utilisation of dropping the freelist. -- nosy: +aimacintyre Added file: http://bugs.python.org/file9392/no-intfloat-freelist.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2039 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
