Mailman 3 June 2000 - Python-Dev

"make test" vs. "-tt"
by Skip Montanaro June 30, 2000

June 30, 2000

Per Fredrik's suggestion, I changed "-tt" to simply "-t". I've not yet done a "cvs update" to grab the tab-corrected versions of whatever files were causing the indigestion. I'm down to a single test failure (test_re) now when running "make test" before .py[co] files have been created. I noticed a couple warnings when test_mmap was running though: ./Lib/sre_compile.py: inconsistent tab/space usage ./Lib/sre_parse.py: inconsistent tab/space usage Could it be that when "-tt" detects a problem it causes a broken .py[co] file to be generated? -- 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."

1 0

--with-cycle-gc switch
by bwarsaw＠beopen.com June 30, 2000

June 30, 2000

I don't like --with-cycle-gc as the configure switch, and unfortunately configure is explicitly designed not to complain about bogus switches. I just typed --without-gc and was momentarily surprised that the module was still enabled. I propose to change the switch to --with(out)-gc and to not recognize --with(out)-cycle-gc. The switch hasn't been there long enough to support both. -Barry

3 3

Removing modules
by Andrew Kuchling June 30, 2000

June 30, 2000

For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist? For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py. Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens... --amk

4 3

Re: [Python-checkins] CVS: distutils/distutils msvccompiler.py,1.33,1.34
by Guido van Rossum June 30, 2000

June 30, 2000

> On second thought, first try for _winreg, and then winreg. Only if both > fail do we try for win32api/win32con. If *those* both fail, then we don't > have registry access. Phew! Is this smart? Doesn't the new winreg have a very different I/F than the old one? --Guido van Rossum (home page: http://www.python.org/~guido/)

3 3

Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,NONE,2.1 Setup.thread.in,2.2,2.3 cPickle.c,2.43,2.44 newmodule.c,2.20,2.21
by bwarsaw＠beopen.com June 30, 2000

June 30, 2000

So, Setup.thread.in isn't used just for threads anymore. Perhaps it should be renamed? At the very least, a comment should be added to the top that this file is for configure enabled modules. -Barry Index: Setup.thread.in =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/Setup.thread.in,v retrieving revision 2.2 retrieving revision 2.3 diff -C2 -r2.2 -r2.3 *** Setup.thread.in 2000/06/29 16:08:28 2.2 --- Setup.thread.in 2000/06/30 05:02:53 2.3 *************** *** 11,12 **** --- 11,15 ---- @USE_THREAD_MODULE@thread threadmodule.c + + # Garbage collection enabled with --with-cycle-gc + @USE_GC_MODULE@gc gcmodule.c

1 0

PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
by Greg Stein June 30, 2000

June 30, 2000

On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838 > > Modified Files: > classobject.c object.c > Log Message: > Trent Mick: change a few casts for Win64 compatibility. > > > Index: classobject.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v > retrieving revision 2.89 > retrieving revision 2.90 > diff -C2 -r2.89 -r2.90 > *** classobject.c 2000/06/23 19:37:01 2.89 > --- classobject.c 2000/06/28 21:57:18 2.90 > *************** > *** 284,288 **** > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); > --- 284,288 ---- > if (v == NULL || !PyString_Check(v)) > return "__name__ must be a string object"; > ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) > return "__name__ must not contain null bytes"; > set_slot(&c->cl_name, v); Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. May as well start some ANSI-fication while we can... Guido: any problem with my changing the macro? Cheers, -g -- Greg Stein, http://www.lyra.org/

7 11

Re: [Python-checkins] CVS: python/dist/src/Tools/perfecthash GenUCNHash.py,1.1,1.2
by Fredrik Lundh June 30, 2000

June 30, 2000

MAL wrote: > out.write(header) > out = open(cFileName, "w") > ! out.write("#include "%s"\n" % headerFileName) > out.write(code) > perfHash.generate_graph(out) umm. I suppose you meant: > ! out.write('#include "%s"\n' % headerFileName) or possibly: > ! out.write("#include \"%s\"\n" % headerFileName) </F>

2 1

CVS locks on SF
by M.-A. Lemburg June 30, 2000

June 30, 2000

I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?): [06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

7 8

SRE status report
by Fredrik Lundh June 30, 2000

June 30, 2000

just checked in a test script for sre. the test_sre file is a copy of test_re, with some minor changes: -- disabled one test (caused by bug #8; see below) -- added T (template mode, experimental, unsupported) and U (unicode locale) flags to the flag test -- removed keyword arguments in pattern test loop: result = obj.search(s, pos=result.start(0), endpos=result.end(0)+1) was changed to: result = obj.search(s, result.start(0), result.end(0)+1) as far as I can tell, the docs don't mention anything about keyword arguments... -- added unicode pattern / target string / locale tests to the pattern test loop. however, the current version SRE doesn't fully pass the test. here's an annotated version of Lib/test/output/test_sre: 1) test_support -- test failed re module pickle 2) test_support -- test failed re module cPickle under SRE, patterns are C objects, not class instances. to allow pickling, I need to modify copy_reg (either by modifing the file itself, or by updating the registry when SRE is first imported). see patch #100650 for more info, 3) === Syntax error: ('(?P<foo_123>a)(?P=foo_123)', 'aa', 0, 'g1', 'a') this is a bug in the SRE parser. should be easy to fix. 4) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') this is a bug in the engine (nested repetitions). needs further research. 5) === Failed incorrectly ('(a+)+\\1', 'aa', 0, 'found+"-"+g1', 'aa-a') this is a bug in the engine or in the parser. needs further research. 6) === grouping error ('([^/]*/)*sub1/', 'd:msgs/tdir/sub1/trial/away.cpp', 0, 'found+"-"+g1', 'd:msgs/tdir/sub1/-tdir/') 'd:msgs/tdir/sub1/-trial/' should be 'd:msgs/tdir/sub1/-tdir/' same as #5. 7) === Syntax error: ('(?P<id>aa)(?P=id)', 'aaaa', 0, 'found+"-"+id', 'aaaa-aa') same as #3. 8) === grouping error ('([abc])*bcd', 'abcd', 0, 'found+"-"+g1', 'abcd-a') 'abcd-c' should be 'abcd-a' this is a bug in the engine. should be easy to fix, I think. in fact, I could have sworn that I'd fixed it already. 9) === grouping error ('(?i)([abc])*bcd', 'ABCD', 0, 'found+"-"+g1', 'ABCD-A') 'ABCD-C' should be 'ABCD-A' same as #8 10) === Syntax error: ('a(?!b).', 'abad', 0, 'found', 'ad') this is bug in the parser. should be easy to fix. 11) === Syntax error: ('a(?=d).', 'abad', 0, 'found', 'ad') same as (or at least related to) #10 12) === Syntax error: ('a(?=c|d).', 'abad', 0, 'found', 'ad') same as #11 13) === Failed incorrectly ('^(.+)?B', 'AB', 0, 'g1', 'A') same as #4 (literally!). ... fwiw, *all* RE-based code I've played with seem to work. ymmv. let me know asap if it does. </F>

1 0

Re: [Python-checkins] CVS: python/dist/src/PCbuild python16.dsp,1.6,1.7
by Trent Mick June 30, 2000

June 30, 2000

On Thu, Jun 29, 2000 at 10:02:55PM -0700, Jeremy Hylton wrote: > Update of /cvsroot/python/python/dist/src/PCbuild > In directory slayer.i.sourceforge.net:/tmp/cvs-serv3220/PCbuild > > Modified Files: > python16.dsp > Log Message: > final patches from Neil Schemenauer for garbage collection > > > Index: python16.dsp > =================================================================== > RCS file: /cvsroot/python/python/dist/src/PCbuild/python16.dsp,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -C2 -r1.6 -r1.7 > *** python16.dsp 2000/06/06 23:29:09 1.6 > --- python16.dsp 2000/06/30 05:02:53 1.7 > *************** > *** 660,663 **** > --- 660,677 ---- > # End Source File > # Begin Source File > + SOURCE=..\Modules\gcmodule.c > + > + !IF "$(CFG)" == "python16 - Win32 Release" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Debug" > + > + !ELSEIF "$(CFG)" == "python16 - Win32 Alpha Release" > + > + !ENDIF > + > + # End Source File > + # Begin Source File > > SOURCE=..\Python\getargs.c > Pardon me if I am wrong (I have not actually checked the repository) but is this correct now that the version number is 2.0? Trent -- Trent Mick trentm(a)activestate.com

2 1

Re: [Python-checkins] CVS: python/dist/src/Include objimpl.h,2.16,2.17
by Jeremy Hylton June 30, 2000

June 30, 2000

These patches should catch up with Neil's latest submissions, but may not have the very latest changes suggested by Neil and Vladimir. I will double-check with them in the morning. I will also change configure.in to enable GC by default for the beta test phase, unless there is strong objection. Jeremy

1 0

Controversial patch (cmath)
by Tim Peters June 30, 2000

June 30, 2000

I just voted to accept a patch that's broken. If you want to argue it, be my guest, but I'm out of it now <wink>. Here's the patch: https://sourceforge.net/patch/?func=detailpatch&patch_id=100651&group_id=547 0 Here's my comment (also available on that page): Accepted (but reluctantly; see below), and assigned back to Guido for checkin. cmathmodule is not production quality, and this patch isn't either, but its asinh and acosh are better than what's there now. The author avoided some of the numerical foolishness in the original, but didn't avoid all of it. For example, it's harder to get asinh to do something ridiculous now than it was before, but still possible: >>> cmath.acosh(1e200) (461.210165779+0j) >>> cmath.asinh(1e200) (1.#INF+0j) >>> asinh should have returned something approximately equal to what acosh returned. That may not be the patch's problem, though! I suspect that's due to one of the module's other functions that's too naive about the limits of floating point. In any case, it is much easier to provoke the *current* cmath functions into cases like this one. Another possible problem has to do with principal values. My reference books are in storage, so about the best I can do right now is compare what this code does to Macsyma (which I have on my laptop). The acosh in this patch often returns the negative of what Macysma computes. For example, >>> cmath.acosh(-1-1j) (1.06127506191-2.23703575929j) >>> Macsyma returns the negation of that. On the other hand, the *original* acosh doesn't agree with Macsyma on some signs where this acosh does. So call this one a wash. I may have mentioned this before <wink>: robust math libraries are extremely difficult to get right. It would take several months to write a production-quality cmath module from scratch, which is several months more than were devoted to Python's current cmath <wink>. I vote we check this in anyway (since it *is*, overall, an improvement), and look into borrowing some other language's complex math library later (note in particular that C9X adds complex numbers and these functions on them, so if we sit on our asses long enough, we can inherit libc's!).

2 2

ANNOUNCE: Distutils 0.9
by Greg Ward June 30, 2000

June 30, 2000

Python Distribution Utilities release 0.9 June 29, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 2.0; if you are running 2.0 (or one of the 1.6 alpha releases that preceded it), you don't need to install the Distutils separately. This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org.

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib sre.py,1.9,1.10 sre_compile.py,1.7,1.8 sre_constants.py,1.7,1.8 sre_parse.py,1.7,1.8
by Greg Stein June 29, 2000

June 29, 2000

Fredrik, Something you are doing is forcing CVS to issue a new revision for some of those files, even when you are not changing them. These "false" revisions are probably not a good thing. Could you review your checkin process to see what is up? I would guess that you have the "-f" option in your commit line. Cheers, -g On Thu, Jun 29, 2000 at 05:38:48AM -0700, Fredrik Lundh wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory slayer.i.sourceforge.net:/tmp/cvs-serv899/Lib > > Modified Files: > sre.py sre_compile.py sre_constants.py sre_parse.py > Log Message: > > > - make sure group names are valid identifiers > (closes the "SRE: symbolic reference" bug) > > Index: sre.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre.py,v > retrieving revision 1.9 > retrieving revision 1.10 > diff -C2 -r1.9 -r1.10 > > Index: sre_compile.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_constants.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_constants.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > > Index: sre_parse.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/sre_parse.py,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -C2 -r1.7 -r1.8 > *** sre_parse.py 2000/06/29 11:34:27 1.7 > --- sre_parse.py 2000/06/29 12:38:45 1.8 > *************** > *** 169,172 **** > --- 169,190 ---- > return this > > + def isident(char): > + return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_" > + > + def isdigit(char): > + return "0" <= char <= "9" > + > + def isname(name): > + # check that group name is a valid string > + # FIXME: <fl> this code is really lame. should use a regular > + # expression instead, but I seem to have certain bootstrapping > + # problems here ;-) > + if not isident(name[0]): > + return 0 > + for char in name: > + if not isident(char) and not isdigit(char): > + return 0 > + return 1 > + > def _group(escape, state): > # check if the escape string represents a valid group > *************** > *** 419,425 **** > if char == ">": > break > - # FIXME: check for valid character > name = name + char > group = 1 > elif source.match("="): > # named backreference > --- 437,444 ---- > if char == ">": > break > name = name + char > group = 1 > + if not isname(name): > + raise error, "illegal character in group name" > elif source.match("="): > # named backreference > *************** > *** 523,540 **** > char = s.get() > if char is None: > ! raise error, "unterminated index" > if char == ">": > break > - # FIXME: check for valid character > name = name + char > if not name: > ! raise error, "bad index" > try: > index = int(name) > except ValueError: > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown index" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > --- 542,560 ---- > char = s.get() > if char is None: > ! raise error, "unterminated group name" > if char == ">": > break > name = name + char > if not name: > ! raise error, "bad group name" > try: > index = int(name) > except ValueError: > + if not isname(name): > + raise error, "illegal character in group name" > try: > index = pattern.groupindex[name] > except KeyError: > ! raise IndexError, "unknown group name" > a((MARK, index)) > elif len(this) > 1 and this[1] in DIGITS: > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins -- Greg Stein, http://www.lyra.org/

2 1

available to look at bugs and patches...
by Skip Montanaro June 29, 2000

June 29, 2000

Barry added me as a developer yesterday. Those people assigning bugs and patches can use me as a resource... Skip

1 0

Mysterious SF message...
by Skip Montanaro June 29, 2000

June 29, 2000

I just submitted a patch for lib/libatexit.tex. In the response page it displayed a list of patches, then the following cryptic message: Patch Uploaded Successfully Added Patch Could Not Send Patch Update Any idea what that means? -- 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

Re: [Python-Dev] Test results of linuxaudiodev.c
by Michael Hudson June 29, 2000

June 29, 2000

Greg Ward <gward(a)mems-exchange.org> writes: > Hi -- > > here are results from testing linuxaudiodev from the latest CVS Python > 1.6. This is on a Dell Dimension with on-board audio hardware: the > Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as > of a week or two ago, and the only one that supports the YMF724). > > Bottom line: the test sound plays, but it sounds horrible when played by > linuxaudiodev. If I do this: > > $ play Lib/test/audiotest.au > > then Cardinal Fang comes through loud and clear. ("play" is a shell > script wrapper for "sox", writing to /dev/dsp.) But if I do this: > > $ ./python Lib/test/regrtest.py test_linuxaudiodev > > he's still audible (and at the same volume), but very scratchy. Sounds > kind of like a very over-driven amp, or like a cheap car radio that > somebody attacked with a knife. > > [...some time passes...] > > OK, I just tried it on another machine, also a Dell but with a different > sound chip: the Crystal CS4232. I'm pretty sure this one is using the > OSS drivers included with the kernel, which is probably the second most > important difference after the chipset itself. Bottom line: it also > sounds horrible. Just tried that here; ouch. I have a Dell Dimension XPS D233 (which has an on-board Yamaha chipset - the OPL2, I believe). I use the sound driver that comes with the redhat built kernel (which is the OSS one I think). $ play audiotest.au sounds fine, $ ../../../build/python regrtest.py test_linuxaudiodev.py \ test_linuxaudiodev sounds horrible; it sounds like it's being rammed through at far too high a volume, but playing with the PCM or volume sliders in gmix has no appreciable effect on the quality. This suggests somewhat that the problem lies in linuxaudiodev.c, doesn't it? Is this stuff, like, documented anywhere? I can't find any helpful manpages... I presume this module must work better than this for some people? Cheers, M.

2 2

documentation patch guidelines
by Fred L. Drake, Jr. June 29, 2000

June 29, 2000

I've updated the patch guidelines for documentation to match other patches, and added a patch category for documentation. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

Re: [Python-Dev] Test results of linuxaudiodev.c
by Michael Hudson June 29, 2000

June 29, 2000

Ka-Ping Yee <pingster(a)ilm.com> writes: > On 29 Jun 2000, Michael Hudson wrote: > > $ play audiotest.au > > > > sounds fine, > > > > $ ../../../build/python regrtest.py test_linuxaudiodev.py \ > > test_linuxaudiodev > > > > sounds horrible; it sounds like it's being rammed through at far too > > high a volume > > Sounds like u-law to me. linuxaudiodev.c selects /dev/dsp by > default, which accepts raw data, not .au format. > > Try setting the environment variable AUDIODEV to /dev/audio > before running the test script. Does that work any better? That's the ticket. "play" and the test now sound identical, modulo some pops & cracks at the start and end of the test. I presume what follows is thus a good idea? Index: test_linuxaudiodev.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_linuxaudiodev.py,v retrieving revision 1.1 diff -u -r1.1 test_linuxaudiodev.py --- test_linuxaudiodev.py 2000/06/10 04:22:57 1.1 +++ test_linuxaudiodev.py 2000/06/29 23:32:55 @@ -17,4 +17,6 @@ def test(): play_sound_file(findfile('audiotest.au')) +os.environ["AUDIODEV"] = "/dev/audio" + test() Cheers, M.

1 0

id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
by Greg Stein June 29, 2000

June 29, 2000

On Wed, Jun 28, 2000 at 02:12:28PM -0700, Guido van Rossum wrote: >... > - chunk #2: > The id() function guarantees a unique return value for different > objects. It does this by returning the pointer to the object. By > returning a PyInt, on Win64 (sizeof(long) < sizeof(void*)) the pointer > is truncated and the guarantee may be proven false. The appropriate > return function is PyLong_FromVoidPtr, this returns a PyLong if that > is necessary to return the pointer without truncation. > > [GvR: note that this means that id() can now return a long on Win32 > platforms. This *might* break some code...] Strictly speaking: the Long only occurs on Win64 platforms. I would guess that it is also possible on say, an Alpha running Linux. Presuming that has 64-bit pointers(?). Regardless: yes, it can certainly break some code. IMO, if any code out there makes any kinds of assumptions about id(), then they deserve to be broken :-) Cheers, -g -- Greg Stein, http://www.lyra.org/

10 14

Test results of linuxaudiodev.c
by Greg Ward June 29, 2000

June 29, 2000

Hi -- here are results from testing linuxaudiodev from the latest CVS Python 1.6. This is on a Dell Dimension with on-board audio hardware: the Yamaha YMF724 chipset. I'm using the ALSA 0.5.8a driver (the latest as of a week or two ago, and the only one that supports the YMF724). Bottom line: the test sound plays, but it sounds horrible when played by linuxaudiodev. If I do this: $ play Lib/test/audiotest.au then Cardinal Fang comes through loud and clear. ("play" is a shell script wrapper for "sox", writing to /dev/dsp.) But if I do this: $ ./python Lib/test/regrtest.py test_linuxaudiodev he's still audible (and at the same volume), but very scratchy. Sounds kind of like a very over-driven amp, or like a cheap car radio that somebody attacked with a knife. [...some time passes...] OK, I just tried it on another machine, also a Dell but with a different sound chip: the Crystal CS4232. I'm pretty sure this one is using the OSS drivers included with the kernel, which is probably the second most important difference after the chipset itself. Bottom line: it also sounds horrible. Greg -- Greg Ward - software developer gward(a)mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

2 1

OT: A Day in the Life of p5p
by Fredrik Lundh June 29, 2000

June 29, 2000

http://prometheus.frii.com/~gnat/yapc/2000-p5p.txt unfortunately, his "What is it with those Python fucks anyway" talk isn't posted... ;-) </F>

13 22

id() on Win64
by Neil Schemenauer June 29, 2000

June 29, 2000

[Greg Stein] >Strictly speaking: the Long only occurs on Win64 platforms. > >I would guess that it is also possible on say, an Alpha running >Linux. Presuming that has 64-bit pointers(?). I think the Alpha is okay. The problem is strange type models were int is 32 bits and pointers are 64. AFAIK, the Alpha uses 64 bits for both. Neil

2 1

Re: [Python-checkins] CVS: python/dist/src/Doc TODO,1.26,1.27
by Moshe Zadka June 29, 2000

June 29, 2000

On Wed, 28 Jun 2000, Fred L. Drake wrote: > + * Update the filecmp documentation (Moshe?). I'm waiting for Gordon to check-in his directory comparisons to filecmp. Gordon? -- Moshe Zadka <moshez(a)math.huji.ac.il> http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com

4 5

arraymodule still broken?
by Fredrik Lundh June 29, 2000

June 29, 2000

just checked everything out and rebuilt, the exceptions problem sure disappeared, but I still get this error: >>> import array >>> array.array("H", [60000]) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: signed short integer is greater than maximum second opinion, anyone? </F>

2 1