[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI

[SourceForge.net]

Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by kerofin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 09:29

Message:
Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:01

Message:
Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

--

Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52

Message:
Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46

Message:
Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 11:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-991754 ] _bsddb segfault

[SourceForge.net]

Bugs item #991754, was opened at 2004-07-15 10:27
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jim Fulton (dcjim)
Assigned to: Gregory P. Smith (greg)
Summary: _bsddb segfault

Initial Comment:
I have to remove the _bsddb extension to run the Python
tests. Otherwise I get a segfault when test_anydbm is
run. I also get a segfault running test_bsddb

uname -r
2.4.22-1.2188.nptlsmp

rpm -q db4
db4-4.1.25-14


gdb ./python
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_bsddb
Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_bsddb
[Thread debugging using libthread_db enabled]
[New Thread -1084317568 (LWP 19122)]
test_bsddb
test__no_deadlock_first (test.test_bsddb.TestBTree) ...
ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084317568 (LWP 19122)]
0x in ?? ()
(gdb) where
#0  0x in ?? ()
(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_anydbm
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_anydbm
[Thread debugging using libthread_db enabled]
[New Thread -1084645248 (LWP 19132)]
test_anydbm
test_anydbm_creation (test.test_anydbm.AnyDBMTestCase)
... ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084645248 (LWP 19132)]
0x in ?? ()
(gdb) where
#0  0x in ?? ()


--

>Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04:07

Message:
Logged In: YES 
user_id=413

I just rewrote the setup.py section that finds the header and library file for 
use when building the bsddb module.  Previously it could pick different 
versions of the header + lib which would compile and link fine but fail at 
runtime.  Its checked in to HEAD.  Could you try that out and let me know if 
that fixes anything for you?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2

[SourceForge.net]

Bugs item #1033390, was opened at 2004-09-23 06:58
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
>Assigned to: Gregory P. Smith (greg)
Summary: build doesn't pick up bsddb w/Mandrake 9.2

Initial Comment:
Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently 
Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the 
list of directories where bsddb 4 is being searched for, and 
rerunning make, seems to fix the problem.  (Problem does not 
appear on Mandrake 9.1, where I had installed sleepycat's stuff 
under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where 
I had a fink-installed one in /sw/lib; no similar problem with any 
other module on any of these platforms, except bsddb).


--

>Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04:15

Message:
Logged In: YES 
user_id=413

Could you try this again using python CVS HEAD.  I just committed a rework of 
setup.py's bsddb library+include file finding code that hopefully does the 
right thing for you.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
>Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 07:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1083895 ] functions replaced by subprocess should point to its docs

[SourceForge.net]

Bugs item #1083895, was opened at 2004-12-12 11:06
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Peter Åstrand (astrand)
Summary: functions replaced by subprocess should point to its docs

Initial Comment:
We should either move or copy the "Replacing Older
Functions with the subprocess Module" section to the
documentation of the functions that are replaced by
subprocess.

See
http://mail.python.org/pipermail/python-dev/2004-December/050266.html,
for non-subprocess specific rationale.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1083177 ] Change in signal function in the signal module

[SourceForge.net]

Bugs item #1083177, was opened at 2004-12-11 07:58
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary H. Loechelt (loechelt)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Change in signal function in the signal module

Initial Comment:
The signal function of the signal module handles
arguments differently in Python 2.4 than in Python 2.3.
 I am running on an HP-UX 11 workstation.  If I set a
handler for a signal that cannot be trapped, like KILL
(signal 9), the signal function accepts the argument in
Python 2.3 but ignores the operation.  However, if I do
the same thing in Python 2.4, the signal function
rejects the argument and raises a RuntimeError.

I am not sure if this change in behavior is intentional
or not.  It makes sense in one way to complain about an
invalid argument (as in Python 2.4) rather than just
ignore the operation (as in Python 2.3).  However, I
did not find this change in either the documentation or
the release notes, and it caught me by surprise. 
Granted, the stricter argument checking probably caught
a sloppy line of coding.  Still, some kind of user
warning would have been nice if this was an intentional
change.

I am enclosing a simple Python script which illustrates
the problem.  It finishes normally when using Python
2.3 and raises a RuntimeError when using Python 2.4:

Traceback (most recent call last):
  File "set_signals.py", line 7, in ?
signal.signal(signal.SIGKILL, dummy)
RuntimeError: (22, 'Invalid argument')

Gary H. Loechelt


--

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-12-14 00:16

Message:
Logged In: YES 
user_id=29957

This is a deliberate change - "errors should not pass
silently". I agree that it should get better visibility.
Perhaps an entry in amk's what's new document in the section
on Porting to 2.4

would be appropriate. AMK? (I've added a comment to the
document as a reminder)


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-11 14:32

Message:
Logged In: YES 
user_id=80475

On WinME, I appropriately get an AttributeError consistently
for Py2.2, Py2.3, and Py2.4.

Anthony, you've made the most recent updates to the
signalmodule.  What do you think?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1078245 ] Python2.4: building '_socket' extension fails with `INET_ADD

[SourceForge.net]

Bugs item #1078245, was opened at 2004-12-03 22:16
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Ströder (stroeder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.4: building '_socket' extension fails with `INET_ADD

Initial Comment:
HI!

I'm trying to build Python2.4 on a rather old Debian
machine. 
Building _socket fails (see below) although I tried to use

configure --disable-ipv6

I've added

#define INET_ADDRSTRLEN 16

to Modules/socketmodule.h which made it work. There
were no problems compiling Python2.2 on the very same
machine.

Ciao, Michael.

-- snip
--
building '_socket' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -I. -I/tmp/Python-2.4/./Include
-I/user/W3311/local/include -I/usr/local/include
-I/tmp/Python-2.4/Include -I/tmp/Python-2.4 -c
/tmp/Python-2.4/Modules/socketmodule.c -o build/t
emp.linux-i686-2.4/socketmodule.o
/tmp/Python-2.4/Modules/socketmodule.c: In function
`socket_inet_ntop':
/tmp/Python-2.4/Modules/socketmodule.c:3350:
`INET_ADDRSTRLEN' undeclared (first use this function)
/tmp/Python-2.4/Modules/socketmodule.c:3350: (Each
undeclared identifier is reported only once
/tmp/Python-2.4/Modules/socketmodule.c:3350: for each
function it appears in.)
/tmp/Python-2.4/Modules/socketmodule.c:3350: size of
array `ip' has non-integer type 

--

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-12-14 00:19

Message:
Logged In: YES 
user_id=29957

How old a debian release is this? It sounds like it's a just
a broken system header, and I'm not entirely convinced that
adding this to the already-large collection of #ifdefs in
socketmodule is a path to happiness.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI

[SourceForge.net]

Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by kerofin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 13:46

Message:
Logged In: YES 
user_id=471223

pyexpat initializes using its internal copy of expat. 
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.

I suspect that this will be a problem if the system version
of expat is newer than Python's.


--

Comment By: Michael Hudson (mwh)
Date: 2004-12-13 13:01

Message:
Logged In: YES 
user_id=6656

1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 09:29

Message:
Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:01

Message:
Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

--

Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52

Message:
Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46

Message:
Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1082874 ] Unable to see Python binary

[SourceForge.net]

Bugs item #1082874, was opened at 2004-12-10 07:26
Message generated for change (Comment added) made by greg_ball
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Prabal Rakshit (prabal_rakshit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to see Python binary

Initial Comment:
After extracting the Python-2.3.3.tar we could get the 
appropriate folder structure. 
We then executed the configure script. Therafter when 
we execute the make command the Python binary is not 
created in /usr/local/bin.

Any pointers??

--

Comment By: Gregory H. Ball (greg_ball)
Date: 2004-12-13 10:45

Message:
Logged In: YES 
user_id=11365

Are you running "make install" after "make" ?

You could try explicitly giving an installation prefix:

./configure --prefix=/usr/local

Otherwise you can look for newly created files like this:

find /usr -mmin -5

Hope this helps.

--

Comment By: Danny Yoo (dyoo)
Date: 2004-12-10 16:19

Message:
Logged In: YES 
user_id=49843

The 'make install' target will copy the built binary to
'/usr/local/bin'.  Did you try 'make install' yet?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 04:07
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 09:38

Message:
Logged In: YES 
user_id=44345

I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse.  While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input.  Python seems not to have problems accepting floating
point inputs with huge numbers of zeroes before or after the
decimal point, but other languages may not be quite so
forgiving.  I think we need to be a bit careful before
changing our implementation.  At the very least we should
probably verify the acceptance of non_e_repr-generated
strings by a few other languages commonly used with XML-RPC
(C, Perl, Tcl, Ruby?).


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 07:13

Message:
Logged In: YES 
user_id=80475

See attached patch.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 06:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071516 ] test_subprocess fails on cygwin

[SourceForge.net]

Bugs item #1071516, was opened at 2004-11-22 23:34
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Jason Tishler (jlt63)
Summary: test_subprocess fails on cygwin

Initial Comment:
[10:29] $python -V
Python 2.4c1
[10:30] $
[10:31] $
[10:31] $python -c 'from test.test_subprocess import
test_main; test_main()' -v
test_args_string (test.test_subprocess.ProcessTestCase)
... ok
test_call_kwargs (test.test_subprocess.ProcessTestCase)
... ok
test_call_seq (test.test_subprocess.ProcessTestCase) ... ok
test_call_string (test.test_subprocess.ProcessTestCase)
... ok
test_communicate (test.test_subprocess.ProcessTestCase)
... ok
test_communicate_pipe_buf
(test.test_subprocess.ProcessTestCase) ... ok
test_communicate_returns
(test.test_subprocess.ProcessTestCase) ... ok
test_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_env (test.test_subprocess.ProcessTestCase) ... ok
test_exceptions (test.test_subprocess.ProcessTestCase)
... ok
test_executable (test.test_subprocess.ProcessTestCase)
... ok
test_invalid_args
(test.test_subprocess.ProcessTestCase) ... ok
test_list2cmdline
(test.test_subprocess.ProcessTestCase) ... ok
test_no_leaking (test.test_subprocess.ProcessTestCase)
... ok
test_poll (test.test_subprocess.ProcessTestCase) ... ok
test_preexec (test.test_subprocess.ProcessTestCase) ... ok
test_run_abort (test.test_subprocess.ProcessTestCase)
... ok
test_shell_sequence
(test.test_subprocess.ProcessTestCase) ... ok
test_shell_string
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_none (test.test_subprocess.ProcessTestCase)
... ok
test_stderr_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_none (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_none (test.test_subprocess.ProcessTestCase)
... this bit of output is from a test of stdout in
a different process ...
ok
test_stdout_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_stderr_file
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines_communicate
(test.test_subprocess.ProcessTestCase) ... ok
test_wait (test.test_subprocess.ProcessTestCase) ... ok
test_writes_before_communicate
(test.test_subprocess.ProcessTestCase) ... ok

==
FAIL: test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 191, in test_stdout_stderr_pipe
self.assertEqual(stripped, "appleorange")
AssertionError: 'apple' != 'appleorange'

==
FAIL: test_universal_newlines
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 312, in test_universal_newlines
"line1\nline2\nline3\nline4\nline5\nline6")
AssertionError: 'line1\n' !=
'line1\nline2\nline3\nline4\nline5\nline6'

--
Ran 37 tests in 109.478s

FAILED (failures=2)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 548, in test_main
test_support.run_unittest(ProcessTestCase)
  File "/usr/lib/python2.4/test/test_support.py", line
290, in run_unittest
run_suite(suite, testclass)
  File "/usr/lib/python2.4/test/test_support.py", line
274, in run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred in
test.test_subprocess.ProcessTestCase


--

>Comment By: Jason Tishler (jlt63)
Date: 2004-12-13 10:04

Message:
Logged In: YES 
user_id=86216

I will look into this problem and why test_shutil failed until
someone hacked the regression test so it passes under
Cygwin now.

Unfortunately, it may be a while before I find adequate time
to debug this problem. ;,(

Peter,

Since you have already devised a test case, would you be
willing to go to the next step and fire up gdb? Any hel

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 11:07
Message generated for change (Comment added) made by pitrou
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Antoine Pitrou (pitrou)
Date: 2004-12-13 20:04

Message:
Logged In: YES 
user_id=133955

I'm gonna ask a stupid question (I'm quite a beginner in
Python). Why isn't there a %f-life formatting code for doing
just what you wrote - printing the float in full precision
in non-exponent format ?



--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 19:12

Message:
Logged In: YES 
user_id=80475

The thought was "be liberal in what you accept and be strict
on was is emitted."  Still, the question is valid.

For C, it looks like strtod() is at the root of everything
converting from floats.  The spec lays no limits on the
input format (exponents vs full decimal representation). 
Instead, it just checks that the result is inside the range
of representable values and did not underflow.  

Some experiments with MSC6 confirm that the full range may
be entered as regular decimals.  Experiments with Perl show
the same result.  I suspect all TCL and Ruby also have
strtod() at the core.


--

Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 16:38

Message:
Logged In: YES 
user_id=44345

I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse.  While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input.  Python seems not to have problems accepting floating
point inputs with huge numbers of zeroes before or after the
decimal point, but other languages may not be quite so
forgiving.  I think we need to be a bit careful before
changing our implementation.  At the very least we should
probably verify the acceptance of non_e_repr-generated
strings by a few other languages commonly used with XML-RPC
(C, Perl, Tcl, Ruby?).


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 14:13

Message:
Logged In: YES 
user_id=80475

See attached patch.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 13:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071516 ] test_subprocess fails on cygwin

[SourceForge.net]

Bugs item #1071516, was opened at 2004-11-23 09:34
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Jason Tishler (jlt63)
Summary: test_subprocess fails on cygwin

Initial Comment:
[10:29] $python -V
Python 2.4c1
[10:30] $
[10:31] $
[10:31] $python -c 'from test.test_subprocess import
test_main; test_main()' -v
test_args_string (test.test_subprocess.ProcessTestCase)
... ok
test_call_kwargs (test.test_subprocess.ProcessTestCase)
... ok
test_call_seq (test.test_subprocess.ProcessTestCase) ... ok
test_call_string (test.test_subprocess.ProcessTestCase)
... ok
test_communicate (test.test_subprocess.ProcessTestCase)
... ok
test_communicate_pipe_buf
(test.test_subprocess.ProcessTestCase) ... ok
test_communicate_returns
(test.test_subprocess.ProcessTestCase) ... ok
test_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_env (test.test_subprocess.ProcessTestCase) ... ok
test_exceptions (test.test_subprocess.ProcessTestCase)
... ok
test_executable (test.test_subprocess.ProcessTestCase)
... ok
test_invalid_args
(test.test_subprocess.ProcessTestCase) ... ok
test_list2cmdline
(test.test_subprocess.ProcessTestCase) ... ok
test_no_leaking (test.test_subprocess.ProcessTestCase)
... ok
test_poll (test.test_subprocess.ProcessTestCase) ... ok
test_preexec (test.test_subprocess.ProcessTestCase) ... ok
test_run_abort (test.test_subprocess.ProcessTestCase)
... ok
test_shell_sequence
(test.test_subprocess.ProcessTestCase) ... ok
test_shell_string
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_none (test.test_subprocess.ProcessTestCase)
... ok
test_stderr_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_none (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_none (test.test_subprocess.ProcessTestCase)
... this bit of output is from a test of stdout in
a different process ...
ok
test_stdout_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_stderr_file
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines_communicate
(test.test_subprocess.ProcessTestCase) ... ok
test_wait (test.test_subprocess.ProcessTestCase) ... ok
test_writes_before_communicate
(test.test_subprocess.ProcessTestCase) ... ok

==
FAIL: test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 191, in test_stdout_stderr_pipe
self.assertEqual(stripped, "appleorange")
AssertionError: 'apple' != 'appleorange'

==
FAIL: test_universal_newlines
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 312, in test_universal_newlines
"line1\nline2\nline3\nline4\nline5\nline6")
AssertionError: 'line1\n' !=
'line1\nline2\nline3\nline4\nline5\nline6'

--
Ran 37 tests in 109.478s

FAILED (failures=2)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 548, in test_main
test_support.run_unittest(ProcessTestCase)
  File "/usr/lib/python2.4/test/test_support.py", line
290, in run_unittest
run_suite(suite, testclass)
  File "/usr/lib/python2.4/test/test_support.py", line
274, in run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred in
test.test_subprocess.ProcessTestCase


--

>Comment By: Peter Åstrand (astrand)
Date: 2004-12-13 20:21

Message:
Logged In: YES 
user_id=344921

I don't think gdb is necessary: we already know the problem:
newlib doesn't loop around read() until all data is read.
Some Cygwin people seems to think that this is not a bug,
but I don't agree. 

--

Comment By: Jason Tishler (jlt63)
Date: 2004-12-13 20:04

Messag

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 13:12

Message:
Logged In: YES 
user_id=80475

The thought was "be liberal in what you accept and be strict
on was is emitted."  Still, the question is valid.

For C, it looks like strtod() is at the root of everything
converting from floats.  The spec lays no limits on the
input format (exponents vs full decimal representation). 
Instead, it just checks that the result is inside the range
of representable values and did not underflow.  

Some experiments with MSC6 confirm that the full range may
be entered as regular decimals.  Experiments with Perl show
the same result.  I suspect all TCL and Ruby also have
strtod() at the core.


--

Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 10:38

Message:
Logged In: YES 
user_id=44345

I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse.  While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input.  Python seems not to have problems accepting floating
point inputs with huge numbers of zeroes before or after the
decimal point, but other languages may not be quite so
forgiving.  I think we need to be a bit careful before
changing our implementation.  At the very least we should
probably verify the acceptance of non_e_repr-generated
strings by a few other languages commonly used with XML-RPC
(C, Perl, Tcl, Ruby?).


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 08:13

Message:
Logged In: YES 
user_id=80475

See attached patch.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 07:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting

[SourceForge.net]

Bugs item #1080864, was opened at 2004-12-07 21:23
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: stas Z (childsplay)
Assigned to: M.-A. Lemburg (lemburg)
Summary: locale.py doesn't recognize valid locale setting

Initial Comment:
[EMAIL PROTECTED]:~$ locale
LANG=nb_NO
[...]

[EMAIL PROTECTED]:~$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09) 
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.3/locale.py", line 346, in
getdefaultlocale
return _parse_localename(localename)
  File "/usr/lib/python2.3/locale.py", line 280, in
_parse_localename
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: nb_NO
>>> 

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-13 20:58

Message:
Logged In: YES 
user_id=38388

Thanks. I've noticed that the C lib doesn't seem to like
"UTF-8" but works well with "UTF8" (no hyphen).

Checking in Lib/locale.py;
/cvsroot/python/python/dist/src/Lib/locale.py,v  <--  locale.py
new revision: 1.30; previous revision: 1.29
done
Checking in Tools/i18n/makelocalealias.py;
/cvsroot/python/python/dist/src/Tools/i18n/makelocalealias.py,v
 <--  makelocalealias.py
new revision: 1.2; previous revision: 1.1
done

Please check again with the updated version.

--

Comment By: stas Z (childsplay)
Date: 2004-12-11 17:18

Message:
Logged In: YES 
user_id=638376

I've looked at the CVS/locale.py but is the utf8 entry missing?
Don't know about the X alias mapping, but I suspect that
there should also be an utf8 entry also for nb_NO/nn_NO.
(Just as there is for no_NO)


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-10 22:58

Message:
Logged In: YES 
user_id=38388

Checking in Lib/locale.py;
/cvsroot/python/python/dist/src/Lib/locale.py,v  <--  locale.py
new revision: 1.29; previous revision: 1.28
done


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-10 14:16

Message:
Logged In: YES 
user_id=38388

Well, if the alias mapping is good enough for X, then it's
good enough for me :-)

I think we ought to update the alias table with the current
data of the X locale.alias file. This file also includes the
mappings that childsplay mentioned.

There also seems to be a bug in the encoding alias table:
"utf" is no longer recognized by setlocale(). This should be
changed to "utf8".

I'll fix that and post an update here.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-10 00:26

Message:
Logged In: YES 
user_id=21627

getdefaultencoding might be "targeted" at the OS level - but
the implementation certainly is not. On the OS level, the C
library will often use a different encoding after
locale.setlocale(locale.LC_ALL,"") is called, compared to
what getdefaultencoding returns. The approach takien inside
getdefaultencoding is inherently flawed, and cannot possibly
work in all cases; getpreferredencoding fixes that flaw.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-09 10:56

Message:
Logged In: YES 
user_id=38388

childsplay (I wish people would use real names on SF...):

We can add the aliases you gave below, but we need some URLs
to add as reference. Please provide this information, so
that we can document that the aliases are in common use and
why iso-8859-1 is their usually used encoding.

Thanks.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-09 10:42

Message:
Logged In: YES 
user_id=38388

Martin: 

"default" as opposed to whatever locale setting is currently
active for the program, i.e. the locale setting the program
would see after a single call to setlocale(LC_ALL, "") right
after the start of the program.

getdefaultlocale() mimics the lookup mechanism of
setlocale(LC_ALL, "").

The fact that the alias table may sometimes not give the
correct encoding is not a fault of Python or the table - if
the user wants to see a different encoding used as default
encoding for the set locale, then the user should include
that information in the LANG (or other) OS environment
variable of the process running the Python program.

Note that this is different than the "preferred" encoding
which a user can set in a window manager (KDE or Gnome) or
browser. Those setti

[ python-Bugs-1084457 ] ossaudiodev no longer undocumented

[SourceForge.net]

Bugs item #1084457, was opened at 2004-12-13 10:26
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: ossaudiodev no longer undocumented

Initial Comment:
The ossaudiodev module can be removed from the list
of undocumented multimedia modules, since documentation
now exists.


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-14 02:20

Message:
Logged In: YES 
user_id=80475

Fixed.

Thanks for the report.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1085069 ] gethostbyaddr on redhat for multiple hostnames

[SourceForge.net]

Bugs item #1085069, was opened at 2004-12-14 12:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Kirby (davekirby)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyaddr on redhat for multiple hostnames

Initial Comment:

When running socket.gethostbyaddr against a host with
multiple hostnames assigned to it, the behaviour does
not work as advertised under Red Hat linux (tested with
Fedora Core 2 and Red Hat 8 - other versions of Linux
have not been tested).  

calling socket.gethostbyaddr from Windows or Mac OS X
against a test machine set up with multiple hosts gives
the correct result:

>>> socket.gethostbyaddr('1.2.3.4')
('testhost2', ['testhost7', 'testhost', 'testhost1',
'testhost3', 'testhost4', 'testhost6', 'testhost5'],
['1.2.3.4'])
>>> 

(The real IP address and hostnames have been changed
for security).

running the same thing from Linux only gives a single
hostname, and the alias list is empty.  Repeated calls
to the same function cycles through the hostnames (or
picks them at random):

>>> socket.gethostbyaddr('1.2.3.4')
('testhost', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost1', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost3', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost4', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost6', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost5', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost2', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost7', [], ['1.2.3.4'])
>>> socket.gethostbyaddr('1.2.3.4')
('testhost', [], ['1.2.3.4'])

This behaviour has been seen with Python 2.2.1, 2.3.3
and 2.4-RC2.

This is probably a bug in the underlying C function. 
According to the Linux man page, the POSIX
gethostbyaddr has been superceded by getipnodebyaddr. 
This behaviour should at least be documented, and if
possible fixed by using the new function.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1085096 ] Fix stale link in PEP

[SourceForge.net]

Bugs item #1085096, was opened at 2004-12-14 07:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Chermside (mcherm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix stale link in PEP

Initial Comment:
As reported to webmaster by Laura Creighton:

In PEP 754 IEEE 754 Floating Point Special Values
http://www.analytics.washington.edu/statcomp/projects/rzope/fpconst/
is stale.  SHould be 
http://research.warnes.net/projects/rzope/fpconst/

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071516 ] test_subprocess fails on cygwin

[SourceForge.net]

Bugs item #1071516, was opened at 2004-11-22 23:34
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470

Category: None
>Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Jason Tishler (jlt63)
Summary: test_subprocess fails on cygwin

Initial Comment:
[10:29] $python -V
Python 2.4c1
[10:30] $
[10:31] $
[10:31] $python -c 'from test.test_subprocess import
test_main; test_main()' -v
test_args_string (test.test_subprocess.ProcessTestCase)
... ok
test_call_kwargs (test.test_subprocess.ProcessTestCase)
... ok
test_call_seq (test.test_subprocess.ProcessTestCase) ... ok
test_call_string (test.test_subprocess.ProcessTestCase)
... ok
test_communicate (test.test_subprocess.ProcessTestCase)
... ok
test_communicate_pipe_buf
(test.test_subprocess.ProcessTestCase) ... ok
test_communicate_returns
(test.test_subprocess.ProcessTestCase) ... ok
test_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_env (test.test_subprocess.ProcessTestCase) ... ok
test_exceptions (test.test_subprocess.ProcessTestCase)
... ok
test_executable (test.test_subprocess.ProcessTestCase)
... ok
test_invalid_args
(test.test_subprocess.ProcessTestCase) ... ok
test_list2cmdline
(test.test_subprocess.ProcessTestCase) ... ok
test_no_leaking (test.test_subprocess.ProcessTestCase)
... ok
test_poll (test.test_subprocess.ProcessTestCase) ... ok
test_preexec (test.test_subprocess.ProcessTestCase) ... ok
test_run_abort (test.test_subprocess.ProcessTestCase)
... ok
test_shell_sequence
(test.test_subprocess.ProcessTestCase) ... ok
test_shell_string
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_none (test.test_subprocess.ProcessTestCase)
... ok
test_stderr_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_none (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_none (test.test_subprocess.ProcessTestCase)
... this bit of output is from a test of stdout in
a different process ...
ok
test_stdout_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_stderr_file
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines_communicate
(test.test_subprocess.ProcessTestCase) ... ok
test_wait (test.test_subprocess.ProcessTestCase) ... ok
test_writes_before_communicate
(test.test_subprocess.ProcessTestCase) ... ok

==
FAIL: test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 191, in test_stdout_stderr_pipe
self.assertEqual(stripped, "appleorange")
AssertionError: 'apple' != 'appleorange'

==
FAIL: test_universal_newlines
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 312, in test_universal_newlines
"line1\nline2\nline3\nline4\nline5\nline6")
AssertionError: 'line1\n' !=
'line1\nline2\nline3\nline4\nline5\nline6'

--
Ran 37 tests in 109.478s

FAILED (failures=2)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 548, in test_main
test_support.run_unittest(ProcessTestCase)
  File "/usr/lib/python2.4/test/test_support.py", line
290, in run_unittest
run_suite(suite, testclass)
  File "/usr/lib/python2.4/test/test_support.py", line
274, in run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred in
test.test_subprocess.ProcessTestCase


--

>Comment By: Jason Tishler (jlt63)
Date: 2004-12-14 04:35

Message:
Logged In: YES 
user_id=86216

I'm happy to report the following newlib patch:

http://sources.redhat.com/ml/newlib-cvs/2004-
q4/msg00031.html

fixes the report problem and test_subprocess passes under
Cygwin CVS as of 20041214.

test_subprocess should pass under Cygwin 1.5.13 (when
released).

Peter, thanks for helping to solve this problem. I real

[ python-Bugs-1085168 ] Uninstaller unclear about the app it's uninstalling

[SourceForge.net]

Bugs item #1085168, was opened at 2004-12-14 15:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninstaller unclear about the app it's uninstalling

Initial Comment:
The "Uninstall Python" link added to the start mrnu
Python 2.4 folder asks "Are you sure you wish to
uninstall this product?". This should really ask
whether you wish to uninstall Python 2.4



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1085172 ] Uninstaller should restore file associations if possible

[SourceForge.net]

Bugs item #1085172, was opened at 2004-12-14 15:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninstaller should restore file associations if possible

Initial Comment:
On installing on Windows, the Python installer
associates .py and .pyw files to the new installation
of python. The installer should cache the previous
associations, and in the event of uninstallation
restore them to their previous values if the
application the are associated with still exists.

This allows for easier migration back to 2.3 in this
case, but also for easier back migration in the case of
installing a beta version of python 2.5 or whatever in
the future.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1076515 ] shutil.move clobbers read-only files.

[SourceForge.net]

Bugs item #1076515, was opened at 2004-12-01 00:40
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Martin v. Löwis (loewis)
Summary: shutil.move clobbers read-only files.

Initial Comment:
The summary states it fine.  shutil.move happily overwrites read-
only files.

It looks like it indiscriminately catches OSError, and never bothers 
to check whether it's a permission error.

It'd be nice if permission errors raised an exception that was a 
subclass of OSError, then it'd be cake to fix this (at least for 
*nices; I'm not sure about the Windows implications).

According to tracker #810879, clobbering read-only files isn't the 
desired behavior for shutil.copyfile, so I doubt it's desired for 
shutil.move.

--

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-12-06 17:21

Message:
Logged In: YES 
user_id=469548

Your analysis is not correct. On Unix, you need write
permission to the *directory* to rename. So the os.rename()
call simply succeeds on a read-only file if you have write
access to its parent directory. I think we could shield from
this by always using the fallback implementation
(copy2+unlink(src)), but I'm not sure what the implications
of that would be (qua performance and cross-platform issues).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()

[SourceForge.net]

Bugs item #994100, was opened at 2004-07-19 14:21
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xb31c,
oparg=0)
at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xb4bc, n=2, 
na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xb4bc,
oparg=2)
at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "", 
globals=0x401bd79c, locals=0x401bd79c,
flags=0xb6cc)
at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
filename=0x80f9fe8 "", flags=0xb6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
filename=0x80f9fe8 "", flags=0xb6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
filename=0x80f9fe8 "", closeit=0,
flags=0xb6cc)
at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xb7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xb7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
libc.so.6 => /lib/libc.so.6 (0x400ba000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


--

>Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04:17

Message:
Logged In: YES 
user_id=413

I just committed a rewrite of the bsddb library+include file finding portion of 
python's setup.py.  Could you try python CVS head on the system you had this 
problem on?  It should now pick a properly paired header file and library 
version.

--

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 19:22

Message:
Logged In: YES 
user_id=44345

I rebuilt it with 3.3, but noticed something I had missed when
it compiled before:

gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-fno-strict-aliasing -I/usr/local/BerkeleyDB.3.2/include -I. 
-I/home/skip/src/Python-2.3.4/./Include -I/usr/local/include 
-I/home/skip/src/Python-2.3.4/Include -I/home/skip/src/Python-2.3.4 -c 
/home/skip/src/Python-2.3.4/Modules/_bsddb.c -o 
build/temp.linux-i686-2.3/_bsddb.o

gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/lib 
-ldb-3.3 -o build/lib.linux-i686-2.3/_bsddb.so

Note that it searches /usr/local/BerkeleyDB.3.2/include for include 
files, but fails to search /usr/

[ python-Bugs-1077040 ] Error building _bsddb extension

[SourceForge.net]

Bugs item #1077040, was opened at 2004-12-01 12:19
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Oleg Broytmann (phd)
>Assigned to: Gregory P. Smith (greg)
Summary: Error building _bsddb extension

Initial Comment:
Trying to build Python 2.4 on Debian GNU/Linux 3.0
using gcc  3.3.4. BerkeleyDB version is 3.2, header is
/usr/include/db.h, library in /usr/lib.

Error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC
-I. -I/usr/local/src/Python/Python-2.4/./Include
-I/usr/local/include
-I/usr/local/src/Python/Python-2.4/Include
-I/usr/local/src/Python/Python-2.4 -c
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o
build/temp.linux-i686-2.4/_bsddb.o
running build_scripts
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In
function `DB_pget':
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464:
error: structure has no member named `pget'
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482:
error: structure has no member named `primaryDBType'
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483:
error: structure has no member named `primaryDBType'
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In
function `DBC_pget':
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928:
error: structure has no member named `c_pget'
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943:
error: structure has no member named `primaryDBType'
/usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944:
error: structure has no member named `primaryDBType'

--

>Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04:13

Message:
Logged In: YES 
user_id=413

Yes this is easy to reproduce.  At the moment the preferred workaround is to 
use a more recent version of BerkeleyDB <= 4.2 (4.3 support has not yet been 
committed to the 2.4 maintenance branch).

I'll fix this so that 3.2 works again shortly.

--

Comment By: Oleg Broytmann (phd)
Date: 2004-12-12 02:47

Message:
Logged In: YES 
user_id=4799

#define DB_VERSION_MAJOR3
#define DB_VERSION_MINOR2
#define DB_VERSION_PATCH9
#define DB_VERSION_STRING   "Sleepycat Software: Berkeley DB
3.2.9: (April  7, 2002)"

--

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2004-12-12 01:23

Message:
Logged In: YES 
user_id=250749

What are the DB_VERSION_MAJOR and DB_VERSION_MINOR macros
defined to in your /usr/include/db.h?

The primaryDBType symbol is only referenced in code compiled
for DB versions 3.3 and higher, and the pget symbol is
referenced in code compiled for DB 3.2 and higher.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI

[SourceForge.net]

Bugs item #1075984, was opened at 2004-11-30 13:13
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

--

>Comment By: Michael Hudson (mwh)
Date: 2004-12-13 13:01

Message:
Logged In: YES 
user_id=6656

1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 09:29

Message:
Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 17:01

Message:
Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

--

Comment By: Michael Hudson (mwh)
Date: 2004-12-10 16:52

Message:
Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 16:46

Message:
Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 08:13

Message:
Logged In: YES 
user_id=80475

See attached patch.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 07:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084457 ] ossaudiodev no longer undocumented

[SourceForge.net]

Bugs item #1084457, was opened at 2004-12-13 10:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: ossaudiodev no longer undocumented

Initial Comment:
The ossaudiodev module can be removed from the list
of undocumented multimedia modules, since documentation
now exists.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084279 ] status of small floats in xml-rpc ?

[SourceForge.net]

Bugs item #1084279, was opened at 2004-12-13 05:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Martin v. Löwis (loewis)
Summary: status of small floats in xml-rpc ?

Initial Comment:
Hi,

I've been reading through the xmlrpclib.py code to see
that floats are marshalled the following way:

def dump_double(self, value, write):
write("")
write(repr(value))
write("\n")
dispatch[FloatType] = dump_double

Using repr() means that small or big floats, for
example, will be output using the exponent notation:
>>> repr(2**-15)
'3.0517578125e-05'

Unfortunately, the XML-RPC specification does not allow
this notation:
"At this time, only decimal point notation is allowed,
a plus or a minus, followed by any number of numeric
characters, followed by a period and any number of
numeric characters. Whitespace is not allowed. The
range of allowable values is implementation-dependent,
is not specified."
(http://www.xmlrpc.com/spec)

Thus floats marshalled using xmlrpclib may not be
readable using other XML-RPC implementations.

(I don't have any concrete data about this though)


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 17:19

Message:
Logged In: YES 
user_id=80475

Various slightly unsatisfactory answers:
* It started out that way because that's what C did.
* It stayed that way because no one has requested it
* It may be that outside of XMLRPC there are very few valid
use cases.
* Future needs can be met by the decimal module.



--

Comment By: Antoine Pitrou (pitrou)
Date: 2004-12-13 14:04

Message:
Logged In: YES 
user_id=133955

I'm gonna ask a stupid question (I'm quite a beginner in
Python). Why isn't there a %f-life formatting code for doing
just what you wrote - printing the float in full precision
in non-exponent format ?



--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 13:12

Message:
Logged In: YES 
user_id=80475

The thought was "be liberal in what you accept and be strict
on was is emitted."  Still, the question is valid.

For C, it looks like strtod() is at the root of everything
converting from floats.  The spec lays no limits on the
input format (exponents vs full decimal representation). 
Instead, it just checks that the result is inside the range
of representable values and did not underflow.  

Some experiments with MSC6 confirm that the full range may
be entered as regular decimals.  Experiments with Perl show
the same result.  I suspect all TCL and Ruby also have
strtod() at the core.


--

Comment By: Skip Montanaro (montanaro)
Date: 2004-12-13 10:38

Message:
Logged In: YES 
user_id=44345

I understand what you''re doing, but I wonder if in the
process interoperability with other XML-RPC implementations
might actually get worse.  While the spec doesn't support
exponential notation, most programming languages do, and
probably happily accept "1.234e-147" as a floating point
input.  Python seems not to have problems accepting floating
point inputs with huge numbers of zeroes before or after the
decimal point, but other languages may not be quite so
forgiving.  I think we need to be a bit careful before
changing our implementation.  At the very least we should
probably verify the acceptance of non_e_repr-generated
strings by a few other languages commonly used with XML-RPC
(C, Perl, Tcl, Ruby?).


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 08:13

Message:
Logged In: YES 
user_id=80475

See attached patch.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-13 07:40

Message:
Logged In: YES 
user_id=80475

I loaded a recipe for a helper function that meets the spec:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361

Inserting and applying the helper function ought to be
backwards compatible (the new encoding is readable by
previous versions).

Martin, do you agree with approach and concur that it should
be backported?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin

[SourceForge.net]

Bugs item #1084766, was opened at 2004-12-13 18:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.stdin segfaults on invalid stdin

Initial Comment:
Bug reported as:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715

If stdin is invalid (e.g., redirected from a directory
by mistake),
python interpreter segfaults on any attempt to access it.

In a case where one actually tries to read sys.stdin, I
would expect
something like

Traceback (most recent call last):
  File "", line 1, in ?
IOError: [Errno 21] Is a directory

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com