Mailman 3 July 2003 - Python-Dev

RE: [Python-Dev] bsddb3 test hang
by Detlef Lannert 23 Jul '03

23 Jul '03

Tim Peters: > [Zooko] > > I wanted to see this bsddb3 explosion for myself, so I tried to build > > the module, but couldn't figure out how to do it. So I opened a bug > > report under the Build category: > > > > [ 775850 ] pybsddb build fails > > > > http://www.python.org/sf/775850 > > You should probably add detailed info to that bug report about the flavor > and version of Linux you're using, since nobody on Python-Dev has reported > problems building 2.3. This is maybe not the same problem that Zooko had, but bsddb doesn't build on my Linux 2.4.10 (SuSE 7.3) box either where Sleepycat db-4.1.25 was installed from the sources. It puts db.h under /usr/local/include per default where Python's setup.py doesn't find it. It used to be sufficient for me to add this directory to the db4 incdirs (see patch below) until 2.3c1 -- but this doesn't work for the CVS version any more. And yes, test_time fails with "AssertionError: AEST", too. For 2.3c1 as well as for current CVS. Detlef *** setup.py.orig Thu Jul 10 14:48:39 2003 --- setup.py Wed Jul 23 14:38:43 2003 *************** *** 490,495 **** --- 490,496 ---- '/opt/sfw/include/db4', '/sw/include/db4', '/usr/include/db4', + '/usr/local/include', )}, 'db3': {'libs': ('db-3.3', 'db-3.2', 'db-3.1', 'db3',), 'libdirs': ('/usr/local/BerkeleyDB.3.3/lib',

1 0

MacPython-OS9 test failures
by Jack Jansen 23 Jul '03

23 Jul '03

Barry (and others), I added a couple of bug reports for things that fail in MacPython-OS9. My personal feeling is that it's best to leave fixing these until the unix/windows/MacOSX release of Python 2.3 has been done. This has the disadvantage that MacPython-OS9 and the rest of the pythons are built from slightly different source trees, but we've done that in the past and no-one seems to be bothered by it. The alternative would be to fix the problems now, with any destabilizing results that may have. Opinions? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

2 1

Serious CallTip Bug in IDLE
by kbk＠shore.net 23 Jul '03

23 Jul '03

Python Bug 775541 Introduced by Python Patch 769142 as applied. I believe this needs to be fixed for rc2. See Python Patch 776062: http://sourceforge.net/tracker/index.php?func=detail&aid=776062&group_id=54… -- KBK

3 2

Test_coercion failing on Panther for complex numbers
by Jack Jansen 23 Jul '03

23 Jul '03

I need a little guidance with bug #775892. I think it's non-serious, but I'm not sure (and I don't know how easy it is to fix). Test_coercion is failing on the beta for MacOSX 10.3. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j).

4 5

optparse 1.4.2 in 2.3: any chance?
by Greg Ward 23 Jul '03

23 Jul '03

I'm so out of the loop I didn't even know 2.3c1 was out until I checked www.python.org/2.3 tonight. ;-( Unfortunately, I was really really hoping to get Optik up to version 1.4.2 in time for Python 2.3. The only changes over 1.4.1 are various small refactorings to make Optik/optparse more easily extensible. This should have no effect on people merely using optparse, and anyone extending it (ie. subclassing Option and/or OptionParser) will win -- unless they're extending it by doing evil things like replacing another module's globals. Given that I won't have a minute to work on this stuff until next Monday (July 28) at the earliest, do I have any hope of getting it into 2.3final? Or should I just face reality and make optparse 1.4.2 the first checkin on the 2.3-maint branch? Greg -- Greg Ward <gward(a)python.net> http://www.gerg.ca/ Quick!! Act as if nothing has happened!

3 2

PyConfig.h On Solaris
by John Abel 22 Jul '03

22 Jul '03

Hi, I apologise if this is an inappropriate post for this list; my query is concerned with the internals of Python, honest :) I am trying to compile a C module on Solaris, to return extended process information (args greater than 80 characters). However, the _FILE_OFFSET_BITS in pyconfig.h is causing me a bit of bother. It is preventing me, from correctly parsing /proc - according to the man pages, any handling of /proc entries must be done with 32bit structures, variables, etc. I've tried undefining it at compile time, without success. I've had to define _LP64, include <procfs.h>, then undefine _LP64. Doing this, allows me to use structured proc, instead of the deprecatd ioctl method. However, I don't think this is a working solution, as the code compiles, runs, but returns dubious results (I have a pure C version of the code, which works fine). I've included the code below. Is there a way, to tell Python to compile a module in 32bit mode? Or, is there a workaround for this Solaris oddity? Regards John #include "Python.h" #include <stdio.h> #define _LP64 #include <procfs.h> #undef _LP64 #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> static PyObject * psinfo_fullpidinfo(PyObject *self, PyObject *args) { PyObject *queryPid; char procBuf[50]; char argStr[512]; char **argvp; int fdPSInfoFile, fdASFile, counter; struct psinfo psBuf; if (!PyArg_ParseTuple(args, "i:pidinfo", &queryPid) ) { return NULL; } (void)sprintf(procBuf,"/proc/%i/psinfo", (int)queryPid); (void)sprintf(asBuf,"/proc/%i/as", (int)queryPid); if ((fdPSInfoFile = open(procBuf, O_RDONLY)) != -1 ) { if (read(fdPSInfoFile, &psBuf, sizeof(struct psinfo)) == sizeof(struct psinfo) ) { close(fdPSInfoFile); if ((fdASFile = open(asBuf, O_RDONLY)) == -1 ) { printf(" Open Of AS Failed"); } else { printf( "%d", psBuf.pr_argc); argvp=(char **) malloc(sizeof(char *) * (psBuf.pr_argc + 1)); if (lseek(fdASFile, psBuf.pr_argv, SEEK_SET) == -1) { printf ("Initial LSeek Failed" ); return NULL; } if (read(fdASFile, argvp, sizeof(char *) * (psBuf.pr_argc + 1)) == -1 ) { printf( "Read Failed" ); return NULL; } for ( counter=0; counter < psBuf.pr_argc; counter++ ) { if (lseek(fdASFile, argvp[ counter ], SEEK_SET) == -1) { printf( "2nd LSeek Failed"); return NULL; } if (read(fdASFile, argStr, 512) == -1) { printf( "Read Of AS File Failed"); return NULL; } printf( "Got %s.\n", argStr ); } close(fdASFile); } } } return Py_BuildValue( "s", argStr ); } static struct PyMethodDef PSInfoMethods[]={ { "fullpidinfo", psinfo_fullpidinfo, METH_VARARGS, "Display Full Arg Details For A Given PID" }, { NULL, NULL, 0, NULL } }; void initpsinfo(void) { (void)Py_InitModule("psinfo", PSInfoMethods); }

3 6

Re: [Python-Dev] bsddb3 test hang
by Zooko 22 Jul '03

22 Jul '03

I wanted to see this bsddb3 explosion for myself, so I tried to build the module, but couldn't figure out how to do it. So I opened a bug report under the Build category: [ 775850 ] pybsddb build fails http://sourceforge.net/tracker/index.php?func=detail&aid=775850&group_id=54… Regards, Zooko > [Tim] > >> The evidence suggests there are still potentially catastrophic bugs > >> in bsddb3! > > [martin(a)v.loewis.de] > > So far, I have interpreted all failures in test_bsddb3 as being > > related to the explicit use of transactions. Since the historic bsddb > > module does not provide an interface for transactions, I have always > > concluded that existing code won't be affected by these problems. > > I'm guessing we're talking about different things, then. These things have > been discussed recently here: > > + Reports of bsddb3 database corruption in spambayes. > > + Likewise in Richie Hindle's multithreaded test driver, plus > hardware faults. > > + Hangs and AssertionErrors in the tests from > Lib/bsddb/test/test_thread.py. > > Richie's program uses only our wrapper's __delitem__, __setitem__ and > __getitem__ implementations. spambayes does the same. While some tests in > test_thread.py use transactions, the AssertionError Skip reported was in a > test that does not use transactions: > > http://mail.python.org/pipermail/python-dev/2003-July/036920.html > > Fred and Barry also saw the same kind of AssertionErrors in > SimpleThreadBase.writerThread, on the same line. Finally, the hangs Barry > and I saw were in test02_SimpleLocks, which is also devoid of transactions. > > So I haven't seen any evidence of problems with transactions -- unless these > things use transactions implicitly in some way. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev >

2 1

2.3rc1 delayed
by Jeremy Hylton 22 Jul '03

22 Jul '03

I've decided to postpone the 2.3 release candidate 1 until Friday. Given the errors reported with current CVS on Cygwin, I don't expect that this release candidate stands much chance of becoming the final release. So I'd rather wait a little and see if anyone can make headway on the Cygwin problems. If we can fix something tomorrow, all the better. If not, we've only lost a day. I also checked in a probable fix for the problem Tim reported when running test_strptime, test_logging, and test_time in that order. I'm not confident that the fix is correct. Basically, it tries to restore the locale to its original value when test_logging finishes. Can someone who understands locales review that change? Please continue to avoid checkins on the head unless the changes are both trivial and critical <0.5 wink>. Jeremy

7 8

RE: [Python-Dev] improved zipimport
by Moore, Paul 22 Jul '03

22 Jul '03

From: Barry Warsaw [mailto:barry@python.org] > On Tue, 2003-07-22 at 10:43, Thomas Heller wrote: >> Is it too late to get this small patch in? >> >> <http://www.python.org/sf/775637> >> >> I'm hesitating to raise the priority... > I'm not a zipimport export but the description seems to imply it's a new > feature not a bug fix. Without more persuasion, I'd say it's too late > for 2.3. I thought this already worked, and I'd like it to. But as it doesn't, I'd have to agree that it's a new feature and not appropriate at this late stage (much as I'd like it to go in). [Mumble, click] Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, but didn't manage to. On the other hand, the fact that it's logged as a bug may mean it makes sense to allow it. Paul.

4 4

bsddb3 test hang
by Barry Warsaw 22 Jul '03

22 Jul '03

I just did a fresh cvs up, configure, build and am running the test suite with TESTOPTS='-u all -v'. It looks like I'm getting a hang in test_bsddb3 on RH9. Running test_bsddb3 alone works just fine. The hang happens at: test02_SimpleLocks (bsddb.test.test_thread.BTreeSimpleThreaded) ... ok So I don't know if it's this test or the next one. I don't have time at the moment to dig further, but one useful thing would be to see if Martin's last checkin to _bsddb.c has any effect. strace-ing the process gives me: % strace -p 26615 futex(0x82fb8c0, FUTEX_WAIT, 0, NULL -Barry

4 8