Mailman 3 August 2000 - Python-Dev

linuxaudiodev test does nothing
by Jeremy Hylton Sept. 1, 2000

Sept. 1, 2000

Is the test for linuxaudiodev supposed to play the Spanish Inquistion .au file? I just realized that the test does absolutely nothing on my machine. (I guess I need to get my ears to raise an exception if they don't hear anything.) I can play the .au file and I use a variety of other audio tools regularly. Is Peter still maintaining it or can someone else offer some assistance? Jeremy

6 11

FW: test_largefile cause kernel panic in Mac OS X DP4
by Tim Peters Sept. 1, 2000

Sept. 1, 2000

-----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Sachin Desai Sent: Thursday, August 31, 2000 2:49 AM To: python-list(a)python.org Subject: test_largefile cause kernel panic in Mac OS X DP4 Has anyone experienced this. I updated my version of python to the latest source from the CVS repository and successfully built it. Upon executing a "make test", my machine ended up in a kernel panic when the test being executed was "test_largefile". My configuration is: Powerbook G3 128M RAM Mac OS X DP4 I guess my next step is to log a bug with Apple. -- http://www.python.org/mailman/listinfo/python-list

2 2

one last SRE headache
by Fredrik Lundh Aug. 31, 2000

Aug. 31, 2000

can anyone tell me how Perl treats this pattern? r'((((((((((a))))))))))\41' in SRE, this is currently a couple of nested groups, surrounding a single literal, followed by a back reference to the fourth group, followed by a literal "1" (since there are less than 41 groups) in PRE, it turns out that this is a syntax error; there's no group 41. however, this test appears in the test suite under the section "all test from perl", but they're commented out: # Python does not have the same rules for \\41 so this is a syntax error # ('((((((((((a))))))))))\\41', 'aa', FAIL), # ('((((((((((a))))))))))\\41', 'a!', SUCCEED, 'found', 'a!'), if I understand this correctly, Perl treats as an *octal* escape (chr(041) == "!"). now, should I emulate PRE, Perl, or leave it as it is... </F> PS. in case anyone wondered why I haven't seen this before, it's because I just discovered that the test suite masks syntax errors under some circumstances...

5 10

Re: [Python-checkins] CVS: python/dist/src/Modules Makefile.pre.in,1.64,1.65
by bwarsaw＠beopen.com Aug. 31, 2000

Aug. 31, 2000

>>>>> "Fred" == Fred L Drake <fdrake(a)users.sourceforge.net> writes: Fred> "Modules/Setup.in is newer than Moodules/Setup;"; \ ! echo ------------------------------------------^^^ who let the cows in here?

1 0

Syntax error in Makefile for "make install"
by Mark Favas Aug. 31, 2000

Aug. 31, 2000

Makefile in the libainstall target of "make install" uses the following construct: @if [ "$(MACHDEP)" == "beos" ] ; then \ This "==" is illegal in all the /bin/sh's I have lying around, and leads to make failing with: /bin/sh: test: unknown operator == make: *** [libainstall] Error 1 -- Mark

2 1

Re: [Python-Dev] stack check on Unix: any suggestions?
by Charles G Waldman Aug. 31, 2000

Aug. 31, 2000

Skip Montanaro writes: > Makes no difference: Allright, I'm confused, I'll shut up now ;-)

1 0

stack check on Unix: any suggestions?
by Mark Favas Aug. 31, 2000

Aug. 31, 2000

On Thu, Aug 31, 2000 at 02:33:28PM +0200, M.-A. Lemburg wrote: >... > At least for my Linux installation a limit of 9000 seems > reasonable. Perhaps everybody on the list could do a quick > check on their platform ? > > Here's a sample script: > > i = 0 > def foo(x): > global i > print i > i = i + 1 > foo(x) > > foo(None) On my DEC/Compaq/OSF1/Tru64 Unix box with the default stacksize of 2048k I get 6225 iterations before seg faulting... -- Mark

4 4

Re: [Python-checkins] CVS: python/dist/src/Misc find_recursionlimit.py,NONE,1.1
by bwarsaw＠beopen.com Aug. 31, 2000

Aug. 31, 2000

I wonder if find_recursionlimit.py shouldn't go in Tools and perhaps be run as a separate rule in the Makefile (with a corresponding cleanup of the inevitable core file, and a printing of the last reasonable value returned). Or you can write a simple Python wrapper around find_recursionlimit.py that did the parenthetical tasks. -Barry

2 2

Re: [Python-Dev] stack check on Unix: any suggestions?
by Martin v. Loewis Aug. 31, 2000

Aug. 31, 2000

> Does anyone have suggestions for how to detect unbounded recursion > in the Python core on Unix platforms? I just submitted patch 101352, at http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470 This patch works on the realistic assumption that reliable stack usage is not available through getrusage on most systems, so it uses an estimate instead. The upper stack boundary is determined on thread creation; the lower stack boundary inside the check. This must allow for initial stack frames (main, _entry, etc), and for pages allocated by on the stack by the system. At least on Linux, argv and env pages count towards the stack limit. If some systems are known to return good results from getrusage, that should be used instead. I have tested this patch on a Linux box to detect recursion in both the example of bug 112943, as well as the foo() recursion; the latter would crash with stock CVS python only when I reduced the stack limit from 8MB to 1MB. Since the patch uses a heuristic to determine stack exhaustion, it is probably possible to find cases where it does not work. I.e. it might diagnose exhaustion, where it could run somewhat longer (rather, deeper), or it fails to diagnose exhaustion when it is really out of stack. It is also likely that there are better heuristics. Overall, I believe this patch is an improvement. While this patch claims to support all of Unix, it only works where getrlimit(RLIMIT_STACK) works. Unix(tm) does guarantee this API; it should work on *BSD and many other Unices as well. Comments? Martin

9 18

Fw: SocketServer and makefile() [from comp.lang.python]
by Fredrik Lundh Aug. 31, 2000

Aug. 31, 2000

iirc, I've been bitten by this a couple of times too (before I switched to asyncore...) any special reason why the input socket is unbuffered by default? </F> ----- Original Message ----- From: "Andy Bond" <bond(a)dstc.edu.au> Newsgroups: comp.lang.python Sent: Thursday, August 31, 2000 8:41 AM Subject: SocketServer and makefile() > I've been working with BaseHTTPServer which in turn uses SocketServer to > write a little web server. It is used to accept PUT requests of 30MB chunks > of data. I was having a problem where data was flowing at the rate of > something like 64K per second over a 100MB network. Weird. Further tracing > showed that the rfile variable from SocketServer (used to suck in data to > the http server) was created using makefile on the original socket > descriptor. It was created with an option of zero for buffering (see > SocketServer.py) which means unbuffered. > > Now some separate testing with socket.py showed that I could whip a 30MB > file across using plain sockets and send/recv but if I made the receivor use > makefile on the socket and then read, it slowed down to my 1 sec per 64K. > If I specify a buffer (something big but less than 64K ... IP packet size?) > then I am back in speedy territory. The unbuffered mode seems almost like > it is sending the data 1 char at a time AND this is the default mode used in > SocketServer and subsequently BaseHTTPServer ... > > This is on solaris 7, python 1.5.2. Anyone else found this to be a problem > or am I doing something wrong? > > andy

3 4