import resource
    soft, hard = resource.getrlimit(
resource.RLIMIT_STACK )
    resource.setrlimit( resource.RLIMIT_STACK, (1024 *
2048, hard))


is the python equivalent of the tcsh 'limit stack 2048'
and will
keep python from seg faulting on test_re . 

( maybe wrapped in a "if os.platform == 'darwin' : "  -- 
  are there any other systems that have this problem ? ) 

-- Steve Majewski

Logged In: YES 
user_id=44345

I tried adding the above code to regrtest.py.  When I tried to 
run python regrtest.py test_re I got a ValueError exception: 
"not allowed to raise maximum limit".  I have no trouble using 
the ulimit builtin command to raise my stack size.  Steve, 
were you perhaps running as root when you tried this?

Logged In: YES 
user_id=44345

BTW, attached is my diff against regrtest.py.

Logged In: YES 
user_id=44345

BTW, attached is my diff against regrtest.py.

Logged In: YES 
user_id=44345

BTW, attached is my diff against regrtest.py.

Logged In: YES 
user_id=44345

Sorry for the bogus updates.  Opera 6.0 Beta 1 apparently has file 
upload problems.  Resorting to IE...

Logged In: YES 
user_id=105602


NOT running as root -- I just tried it again and verified
that it 
works for me.  HOWEVER: I haven't yet upgraded to Jaguar/10.2 
Maybe that's the difference ?  

I can post a request on the pythonmac list and ask some
others to
try it  and find out if it's a 10.1.x vs 10.2 thing.   -- Steve

Logged In: YES 
user_id=12800

I can verify the patch works on 10.1, specifically the OSX
Server in the SF compile farm.

Logged In: YES 
user_id=34209

I'd suggest adding a min(max, <new limit>) to the patch, so
that it becomes:

soft, hard = resource.getrlimit(resource.RLIMIT_STACK)
newsoft = min(hard, max(soft, 1024*2048))
resource.setrlimit(resource.RLIMIT_STACK, newsoft, hard)

And if the test suite only triggers this problem, doesn't it
make more sense in s?re.py, as Fredrik suggested ?

Logged In: YES 
user_id=34209

Oh, and the diff is kind of amusing. It seems to be
MacBinary, but 'file' on my Debian machine isn't quite sure:

/home/thomas/regrtest.diff: MacBinary III data with
surprising version number

Fortunately it's still readable :-) I guess I should go back
to "cool with a Macintosh" too.

Logged In: YES 
user_id=12800

Ok, I've added the Wouters Elaboration to regrtest.py and
verified it works on both 10.1 and 10.2 (the former being
the OSX machine on the SF compile farm and the latter being
my home machine).  Attached is the patch (I hope :).

(Aside: why does this build `python' for 10.1 but
`python.exe' for 10.2?)

I think this patch is fine for Py2.2.2.  Today Guido said
he'd feel more comfortable with a patch to main.c than a
patch to regrtest.py, s?re.py, or site.py (if I understood
him correctly).  However, I don't think there's time for
that for Py2.2.2.  Perhaps we should simply commit this
simple fix so the test suite passes, and then work out a
more comprehensive patch for Py2.3?

Note that In addition, here is the output of the regrtest on
10.1 and 10.2.  Is it worth spending time trying to fix
these for the Py2.2.2 release?

10.1:

170 tests OK.
2 tests failed:
    test_fcntl test_largefile
21 tests skipped:
    test_al test_cd test_cl test_curses test_dl
test_email_codecs
    test_gdbm test_gl test_imgfile test_linuxaudiodev
test_locale
    test_minidom test_poll test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
3 skips unexpected on darwin:
    test_sax test_pyexpat test_locale
make: *** [test] Error 1

10.2:

171 tests OK.
1 test failed:
    test_locale
21 tests skipped:
    test_al test_cd test_cl test_curses test_dl
test_email_codecs
    test_gdbm test_gl test_imgfile test_linuxaudiodev
test_minidom
    test_nis test_poll test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
2 skips unexpected on darwin:
    test_sax test_pyexpat

Logged In: YES 
user_id=6656

> (Aside: why does this build `python' for 10.1 but
> `python.exe' for 10.2?)

Because the sf machine has a case sensitive filesystem?

I don't see any failures on 10.1.5 (after I ran ulimit, duh).

Haven't tried this patch yet...

Logged In: YES 
user_id=33168

Anybody, is this patch still necessary?  Have the problems
been fixed?

Logged In: YES 
user_id=12800

Yes, I think this problem still exists, but we haven't
decided what to do about it.  I'm assigning it to Jack for
final disposition.

Logged In: YES 
user_id=45365

The problem seems to be gone. I'm running with the default stack size limit 
(512KB) and the test runs fine.