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
[mailto:firstname.lastname@example.org]On Behalf Of Sachin Desai
Sent: Thursday, August 31, 2000 2:49 AM
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:
Mac OS X DP4
I guess my next step is to log a bug with Apple.
can anyone tell me how Perl treats this pattern?
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...
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...
>>>>> "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?
Makefile in the libainstall target of "make install" uses the following
@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
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
On my DEC/Compaq/OSF1/Tru64 Unix box with the default stacksize of 2048k
I get 6225 iterations before seg faulting...
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.
> Does anyone have suggestions for how to detect unbounded recursion
> in the Python core on Unix platforms?
I just submitted patch 101352, at
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.
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
----- Original Message -----
From: "Andy Bond" <bond(a)dstc.edu.au>
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?