Mailman 3 June 2000 - Python-Dev

Idle breakage
by Neil Schemenauer 01 Jul '00

01 Jul '00

Caused by _sre perhaps? $ python Tools/idle/idle.py Traceback (most recent call last): File "Tools/idle/idle.py", line 8, in ? IdleConf.load(idle_dir) File "Tools/idle/IdleConf.py", line 109, in load idleconf.read((os.path.join(dir, "config.txt"), genplatfile, platfile, File "/usr/local/lib/python2.0/ConfigParser.py", line 207, in read self.__read(fp, filename) File "/usr/local/lib/python2.0/ConfigParser.py", line 382, in __read raise e ConfigParser.ParsingError: File contains parsing errors: Tools/idle/config.txt [line 21]: 'width= 80\012' [line 22]: 'height= 24\012' [line 26]: 'normal-foreground= black\012' [line 27]: 'normal-background= white\012' [line 29]: 'keyword-foreground= #ff7700\012' [line 30]: 'comment-foreground= #dd0000\012' [line 31]: 'string-foreground= #00aa00\012' [line 32]: 'definition-foreground= #0000ff\012' [line 33]: 'hilite-foreground= #000068\012' [line 34]: 'hilite-background= #006868\012' [line 35]: 'break-foreground= #ff7777\012' [line 36]: 'hit-foreground= #ffffff\012' [line 37]: 'hit-background= #000000\012' [line 38]: 'stdout-foreground= blue\012' [line 39]: 'stderr-foreground= red\012' [line 40]: 'console-foreground= #770000\012' [line 41]: 'error-background= #ff7777\012' [line 42]: 'cursor-background= black\012' [line 59]: 'enable= 0\012' [line 60]: 'style= expression\012' [line 61]: 'flash-delay= 500\012' [line 62]: 'bell= 1\012' [line 63]: 'hilite-foreground= black\012' [line 64]: 'hilite-background= #43cd80\012'

5 13

Windows build issues
by Neil Schemenauer 01 Jul '00

01 Jul '00

A couple of things: PCbuild/readme.txt Should be updated for the new release. PC/config.h VC++ 5.0 will not compile python20 unless "#include <basetsd.h>" is commented out. Trent? WITH_CYCLE_GC should be uncommented if we want to have GC enabled in the beta. PCbuild/python20.dsp Line endings seem to be incorrect. Someone probably edited the file on a Unix machine and munched things up. VC++ 5.0 likes DOS line endings otherwise it refuses to load the project. Also, I get a few warnings when compiling. One is about an /IZ (I think) option being ignored. There are a few other warnings as well which I didn't write down. Neil

4 3

Checked in new PC\config.h
by Mark Hammond 01 Jul '00

01 Jul '00

Hi all, I noticed that PC\config.h still had a reference to "Python16.lib". I simply checked in a new version without submitting a patch or following any other process. I hope this was appropriate. Mark.

4 3

Updating patches on SF
by Neil Schemenauer 30 Jun '00

30 Jun '00

WTF is going on? I did successfully update one of my patches but now that feature no longer seems to work. I get the message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update and the old patch remains. Neil

1 1

Oops on AIX
by Vladimir.Marangozov＠inrialpes.fr 30 Jun '00

30 Jun '00

After the CVS commit storm that occurred during the last 3 days, I wanted to validate the current build on AIX. And I am stalled. I am not sure, but it seems like the errors I get relate with the latest 64-bit support patches, and I don't dare to suggest corrections in this area, so I welcome any help... xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c "methodobject.c", line 183.36: 1506-280 (E) Function argument assignment between types "void*" and "struct _object*(*)(struct _object*,struct _object*)" is not allowed. xlc_r -O -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c "./posixmodule.c", line 293.16: 1506-213 (S) Macro name STAT cannot be redefined. "./posixmodule.c", line 293.16: 1506-358 (I) "STAT" is defined on line 170 of /usr/include/sys/dir.h. make: 1254-004 The error code from the last command is 1. Thanks. -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 2

Odd behavior with `make test'
by bwarsaw＠beopen.com 30 Jun '00

30 Jun '00

make test is behaving strangely. The first time I ran it I got test test_mmap crashed -- exceptions.SyntaxError : inconsistent use of tabs and spaces in indentation which I believe Jeremy has seen with test_sre. tabnanny says everything's fine, and running the module manually (and individually w/ regrtest) shows no problems with the test. Similarly, I got a different crash in test_sre. It says: test test_sre failed -- sre.search and I also get test test_re failed -- re.search I'm also getting bizare stuff like test test_strftime crashed -- exceptions.AttributeError : match test test_tokenize crashed -- exceptions.AttributeError : compile test test_xmllib crashed -- exceptions.AttributeError : compile This is all with a CVS updated Python 2.0b1. Now if I run "./python Lib/test/test_mmap.py" manually, this succeeds, and now either the failures go away or are transmorgrified into something more reasonable: mmap, strftime, tokenize, sre, and xmllib all pass. test_re still fails, but this time with test test_re failed -- Writing: '=== Failed incorrectly', expected: "('abc', 'abc', 0, 'fou" Blowing away the Lib/test/*.pyc's doesn't seem to re-trigger the problem once it's fixed, but doing a `make distclean' and `make test' gets me back to the initial situation. Weird! -Barry

3 5

Fwd: Re: last minute GC questions
by Neil Schemenauer 30 Jun '00

30 Jun '00

Oops, should have cc python-dev. ----- Forwarded message from Neil Schemenauer <nascheme(a)enme.ucalgary.ca> ----- Date: Fri, 30 Jun 2000 15:27:48 -0600 From: Neil Schemenauer <nascheme(a)enme.ucalgary.ca> Subject: Re: last minute GC questions To: Jeremy Hylton <jeremy(a)beopen.com> X-Url: http://www.enme.ucalgary.ca/~nascheme/ On Fri, Jun 30, 2000 at 04:57:44PM -0400, Jeremy Hylton wrote: > Might we change the strategy for deciding when to collect? We might. :) > It seems to me that counting deallocations only would be more > effective. It is only the deallocations that cause a live object to > become garbage. You can easily run out of memory with that strategy though: N = 10000 while 1: l = [] for i in xrange(N): l.append([]) l[0] = l You only get a couple of deallocations while a large amount of garbage is created. Think of large cyclic structures like graphs being created and then becoming garbage due to one deallocation. By counting the net new objects we guarantee that this doesn't happen. > The other part of the strategy that might be changed is the collection > frequency. Right now, the threshold is 100 net allocations & > dealloactions. On the compiler benchmark, this leads to some 2600 > collections, which seems like a lot. (I have no idea why it seems > like a lot, but it does.) Try setting the threshold to zero. The major part of the GC overhead does not seem to be running the collector. OTOH, the frequency could probably be decreased without the risk of running out of memory. No Python applications currently exist that create that amount of garbage anyhow. Neil ----- End forwarded message -----

1 0

Re: [Python-checkins] CVS: python/dist/src/Misc COPYRIGHT,1.4,1.5
by Skip Montanaro 30 Jun '00

30 Jun '00

Fred> The new copyright / license. ... Fred> ! ... IN NO EVENT SHALL THE REGENTS OR Fred> ! CONTRIBUTORS BE LIABLE FOR ... Who are the "regents" and the "contributors"? Should those terms be defined somewhere? not-a-lawyer-and-never-wanted-to-be-ly y'rs, -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings."

2 1

last minute GC questions
by Jeremy Hylton 30 Jun '00

30 Jun '00

I've got two last minute questions. Does it look to you like I checked in all of the changes that you and Vladimir discussed? Might we change the strategy for deciding when to collect? There are two parts of the strategy that could probably change. The first is what kind of allocation events we count to determine when to collect. Right now, the gc is counting the net effect of allocations and deallocations. This isn't effective for at least a couple of cases. If we allocate N objects and don't deallocate anything, then no garbage is going to be created. If we have many objects currently allocated and then dealloc N objects without allocating any, we could create collectible garbage, but the collector won't run because there haven't been any allocations. It seems to me that counting deallocations only would be more effective. It is only the deallocations that cause a live object to become garbage. The other part of the strategy that might be changed is the collection frequency. Right now, the threshold is 100 net allocations & dealloactions. On the compiler benchmark, this leads to some 2600 collections, which seems like a lot. (I have no idea why it seems like a lot, but it does.) I experimented with a policy that runs the collected every N deallocations (not counting deallocations the occur during a collection). I set N == 1000 and got 1600 collections on the compiler benchmark. There is only a small speedup (just a few percent), so maybe this change doesn't have a big effect. I don't recall much about the cost/complexity of various GC approaches. Jeremy

2 1

Re: Test results of linuxaudiodev.c
by Michael Hudson 30 Jun '00

30 Jun '00

To python-dev: Sorry for the hiatus. To python-list: does someone who knows about audio and can run linux want to play with this (Ping and I fall into just one of these categories each!). Ka-Ping Yee <pingster(a)ilm.com> writes: > On 30 Jun 2000, Michael Hudson wrote: > > Yup, that works fine. Don't understand the details - and as I have my > > graduation ceremony tomorrow I'm going to go to bed and leave learning > > them until some other occasion! > > Cool. > > Okay, i just discovered sunau.py. Here's my real shot at > test_linuxaudiodev.py. Can you give this a try? > > > ---- test_linuxaudiodev.py ---- > from test_support import verbose, findfile, TestFailed > import linuxaudiodev > import os, sunau > > formats = {("ULAW", 1): linuxaudiodev.AFMT_MU_LAW, > ("NONE", 1): linuxaudiodev.AFMT_S8, > ("NONE", 2): linuxaudiodev.AFMT_S16_BE} > > def play_au_file(path): > au = sunau.open(path, "r") > data = au.readframes(sunau.AUDIO_UNKNOWN_SIZE) > au.close() > > spec = (au.getcomptype(), au.getsampwidth()) > if not has_key(formats, spec): ^^^^^^^ Oops? > raise "audio format not supported by linuxaudiodev" Maybe you mean: raise TestFailed, "audio format not supported by linuxaudiodev" ? I thought string exceptions were deprecated... > dsp = linuxaudiodev.open("w") > dsp.setparameters(au.getframerate(), au.getsampwidth() * 8, > au.getnchannels(), formats[spec]) > dsp.write(data) > dsp.close() > > def test(): > play_au_file(findfile('audiotest.au')) > > test() This doesn't work. I don't really understand why. For audiotest.au, |spec| is ("ULAW",2), which I don't think is right; file(1) says audiotest.au: Sun/NeXT audio data: 8-bit ISDN u-law, mono, 8000 Hz So I think this could be a bug in sunau. The other data (au.getframerate(), au.getnchannels()) agrees with file(1). Anybody have a better idea? Cheers, Michael Hudson, BA (as of today! woohoo!)

1 0