Mailman 3 September 2000 - Python-Dev

Re: [Python-Dev] Thread problems on Linux
by Neil Schemenauer 04 Sep '00

04 Sep '00

On Mon, Sep 04, 2000 at 10:04:40AM -0500, Charles G Waldman wrote: >If you replace pthread_create with clone you have a lot of work to do >to implement the locking stuff... Locks exist in /usr/include/asm. It is Linux specific but so is clone(). Neil

1 0

Even more prerelease Python fun on Windows!
by Tim Peters 04 Sep '00

04 Sep '00

As below, except the new file is /pub/windows/beopen-python2b1p2-20000901.exe 5,783,115 bytes still from anonymous FTP at python.beopen.com. The p1 version has been removed. + test_popen2 should work on Windows 2000 now (turned out that, as feared, MS "more" doesn't work the same way across Windows flavors). + Minor changes to the installer. + New LICENSE.txt and README.txt in the root of your Python installation. + Whatever other bugfixes people committed in the 8 hours since 2b1p1 was built. Thanks for the help so far! We've learned that things are generally working well, on Windows 2000 the correct one of "admin" or "non-admin" install works & is correctly triggered by whether the user has admin privileges, and that Thomas's Win98FE suffers infinitely more blue-screen deaths than Tim's Win98SE ever did <wink>. Haven't heard from anyone on Win95, Windows Me, or Windows NT yet. And I'm downright eager to ignore Win64 for now. -----Original Message----- Sent: Friday, September 01, 2000 7:35 AM To: PythonDev; Audun.Runde(a)sas.com Cc: audun(a)mindspring.com Subject: [Python-Dev] Prerelease Python fun on Windows! A prerelease of the Python2.0b1 Windows installer is now available via anonymous FTP, from python.beopen.com file /pub/windows/beopen-python2b1p1-20000901.exe 5,766,988 bytes Be sure to set FTP Binary mode before you get it. This is not *the* release. Indeed, the docs are still from some old pre-beta version of Python 1.6 (sorry, Fred, but I'm really sleepy!). What I'm trying to test here is the installer, and the basic integrity of the installation. A lot has changed, and we hope all for the better. Points of particular interest: + I'm running a Win98SE laptop. The install works great for me. How about NT? 2000? 95? ME? Win64 <shudder>? + For the first time ever, the Windows installer should *not* require adminstrator privileges under NT or 2000. This is untested. If you log in as an adminstrator, it should write Python's registry info under HKEY_LOCAL_MACHINE. If not an adminstrator, it should pop up an informative message and write the registry info under HKEY_CURRENT_USER instead. Does this work? This prerelease includes a patch from Mark Hammond that makes Python look in HKCU before HKLM (note that that also allows users to override the HKLM settings, if desired). + Try python lib/test/regrtest.py test_socket is expected to fail if you're not on a network, or logged into your ISP, at the time your run the test suite. Otherwise test_socket is expected to pass. All other tests are expected to pass (although, as always, a number of Unix-specific tests should get skipped). + Get into a DOS-box Python, and try import Tkinter Tkinter._test() This installation of Python should not interfere with, or be damaged by, any other installation of Tcl/Tk you happen to have lying around. This is also the first time we're using Tcl/Tk 8.3.2, and that needs wider testing too. + If the Tkinter test worked, try IDLE! Start -> Programs -> Python20 -> IDLE. + There is no time limit on this installation. But if you use it for more than 30 days, you're going to have to ask us to pay you <wink>. windows!-it's-not-just-for-breakfast-anymore-ly y'rs - tim _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://www.python.org/mailman/listinfo/python-dev

5 7

Re: [Python-Dev] Thread problems on Linux
by Charles G Waldman 04 Sep '00

04 Sep '00

Neil wrote: >I'm thinking of creating a thread_linux header file. Do you think that >would be a good idea? clone() seems to be pretty easy to use although >it is quite low level. Sounds like a lot of work to me. The pthread library gets us two things (essentially) - a function to create threads, which you could pretty easily replace with clone(), and other functions to handle mutexes and conditions. If you replace pthread_create with clone you have a lot of work to do to implement the locking stuff... Of course, if you're willing to do this work, then more power to you. But from my point of view, I'm at a site where we're using pthreads on Linux in non-Python applications as well, so I'm more interested in diagnosing and trying to fix (or at least putting together a detailed and coherent bug report on) the platform bugs, rather than trying to work around them in the Python interpreter.

1 0

Thread problems on Linux
by Charles G Waldman 04 Sep '00

04 Sep '00

No, I still don't have the answer, but I came across a very interesting bit in the `info' files for glibc-2.1.3. Under a heading "Specific Advice for Linux Systems", along with a bunch of info about installing glibc, is this gem: > You cannot use `nscd' with 2.0 kernels, due to bugs in the > kernel-side thread support. `nscd' happens to hit these bugs > particularly hard, but you might have problems with any threaded > program. Now, they are talking about 2.0 and I assume everyone here running Linux is running 2.2. However it makes one wonder whether all the bugs in kernel-side thread support are really fixed in 2.2. One of these days we'll figure it out...

4 3

mail sent as "root"
by Charles G Waldman 04 Sep '00

04 Sep '00

sorry for the mail sent as "root" - d'oh. I still am not able to send mail from fnal.gov to python.org (no route to host) and am playing some screwy games to get my mail delivered.

1 0

ME so mmap
by Tim Peters 04 Sep '00

04 Sep '00

Audun S. Runde mailto:audun@mindspring.com wins a Fabulous Prize for being our first Windows ME tester! Also our only, and I think he should get another prize just for that. The good news is that the creaky old Wise installer worked. The bad news is that we've got a Windows-ME-specific std test failure, in test_mmap. This is from the installer available via anonymous FTP from python.beopen.com, /pub/windows/beopen-python2b1p2-20000901.exe 5,783,115 bytes and here's the meat of the bad news in Audun's report: > PLATFORM 2. > Windows ME > (version/build 4.90.3000 aka. "Techical Beta Special Edition" > -- claimed to be identical to the shipping version), > no previous Python install > ============================================================= > > + Try > python lib/test/regrtest.py > > --> results: > 76 tests OK. > 1 test failed: test_mmap (see below) > 23 tests skipped (al, cd, cl, crypt, dbm, dl, fcntl, fork1, gdbm, gl, grp, > imgfile, largefile, linuxaudiodev, minidom, nis, openpty, poll, pty, pwd, > signal, sunaudiodev, timing) > > Rerun of test_mmap.py: > ---------------------- > C:\Python20\Lib\test>..\..\python test_mmap.py > Traceback (most recent call last): > File "test_mmap.py", line 121, in ? > test_both() > File "test_mmap.py", line 18, in test_both > m = mmap.mmap(f.fileno(), 2 * PAGESIZE) > WindowsError: [Errno 6] The handle is invalid > > C:\Python20\Lib\test> > > > --> Please let me know if there is anything I can do to help with > --> this -- but I might need detailed instructions ;-) So we're not even getting off the ground with mmap on ME -- it's dying in the mmap constructor. I'm sending this to Mark Hammond directly because he was foolish enough <wink> to fix many mmap-on-Windows problems, but if any other developer has access to ME feel free to grab this joy away from him. There are no reports of test_mmap failing on any other flavor of Windows (& clean reports from 95, 2000, NT, 98), looks extremely unlikely that it's a flaw in the installer, and it's a gross problem right at the start. Best guess now is that it's a bug in ME. What? A bug in a new flavor of Windows?! Na, couldn't be ... may-as-well-believe-that-money-doesn't-grow-on-trees-ly y'rs - tim

1 0

New commands to display license, credits, copyright info
by Guido van Rossum 04 Sep '00

04 Sep '00

The copyright in 2.0 will be 5 or 6 lines (three copyright statements, with an "All Rights Reserved" for each -- according to CNRI's wishes). This will cause a lot of scrolling at the start of a session. Does anyone care? Bob Weiner (my boss at BeOpen) suggested that we could add commands to display such information instead. Here's a typical suggestion with his idea implemented: Python 2.0b1 (#134, Sep 3 2000, 10:04:03) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "license" or "credits" for this information. >>> copyright Copyright (c) 2000 BeOpen.com; All Rights Reserved. Copyright (c) 1995-2000 Corporation for National Research Initiatives; All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam; All Rights Reserved. >>> credits A BeOpen PythonLabs-led production. >>> license HISTORY OF THE SOFTWARE ======================= Python was created in the early 1990s by Guido van Rossum at Stichting Mathematisch Centrum (CWI) in the Netherlands as a successor of a language called ABC. Guido is Python's principal author, although it . .(etc) . Hit Return for more, or q (and Return) to quit: q >>> How would people like this? (The blank line before the prompt is unavoidable due to the mechanics of how objects are printed.) Any suggestions for what should go in the "credits" command? (I considered taking the detailed (messy!) GCC version info out as well, but decided against it. There's a bit of a tradition in bug reports to quote the interpreter header and showing the bug in a sample session; the compiler version is often relevant. Expecting that bug reporters will include this information manually won't work. Instead, I broke it up in two lines.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

7 6

libdb on by default, but no db.h
by Vladimir.Marangozov＠inrialpes.fr 04 Sep '00

04 Sep '00

On my AIX combo, configure assumes --with-libdb (yes) but reports that ... checking for db_185.h... no checking for db.h... no ... This leaves the bsddbmodule enabled but it can't compile, obviously. So this needs to be fixed ASAP. -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 4

Re: [Python-Dev] stack check on Unix, etc
by Charles G Waldman 04 Sep '00

04 Sep '00

Skip Montanaro write: > When I configure --without-threads, the script runs much longer, > making it past 18068. It conks out in the same spot, however, > trying to print 18069. I am utterly unable to reproduce this. With "ulimit -s unlimited" and a no-threads version of Python, "find_recursionlimit" ran overnight on my system and got up to a recursion depth of 98,400 before I killed it off. It was using 74MB of stack space at this point, and my system was running *really* slow (probably because my pathetic little home system only has 64MB of physical memory!). Are you absolutely sure that when you built your non-threaded Python you did a thorough housecleaning, eg. "make clobber"? Sometimes I get paranoid and type "make distclean", just to be sure - but this shouldn't be necessary, right? Can you give me more info about your system? I'm at kernel 2.2.16, gcc 2.95.2 and glibc-2.1.3. How about you? I've got to know what's going on here, because your experimental results don't conform to my theory, and I'd rather change your results than have to change my theory <wink> quizzically yr's, -C

2 1

Re: [Python-Dev] New commands to display license, credits, copyright info
by root 04 Sep '00

04 Sep '00

Jeremy wrote: > I think the meaning is clear if the phrasing is awkward. Would 'that' > be any better than 'this'? To my ears, "that" is just as awkward as "this". But in this context, I think "more" gets the point across and sounds much more natural.

1 0