[ python-Bugs-1526585 ] Concatenation on a long string breaks

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Armin Rigo (arigo)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

[EMAIL PROTECTED]:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


--

>Comment By: Armin Rigo (arigo)
Date: 2006-07-26 09:01

Message:
Logged In: YES 
user_id=4771

I'm unsure about how the bigmem tests should be used.
I think that I am not supposed to set a >2G limit on
a 32-bit machine, right?  When I do, I get 9 failures:
8 OverflowErrors and a stranger AssertionError in
test_hash.  I think that these tests are meant to
test the int/Py_ssize_t difference on 64-bit 
machines instead.  The bug this tracker is about
only shows up on 32-bit machines.

My concern is that if we add a test for the current
bug in test_bigmem, then with a memory limit < 2GB
the test is essentially skipped, and with a memory
limit > 2GB then 9 other tests fail anyway.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 04:19

Message:
Logged In: YES 
user_id=33168

Armin, can you check in your patch and backport?  Also a
news entry and a test in test_bigmem would be great. 
Thanks.  If not let me know (assign to me) and I'll finish
this up.

This fix should be backported as well.

--

Comment By: Jp Calderone (kuran)
Date: 2006-07-25 20:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


--

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 18:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-25 03:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
> Py_ssize_t new_len = v_len + w_len;
> if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 03:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

  Py_ssize_t new_len = v_len + w_len;
  if (new_len < 0) {

Jp, can you test the patch?

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 14:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

--

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 09:00

Message:
Logged In: 

[ python-Bugs-978833 ] SSL-ed sockets don't close correct?

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL-ed sockets don't close correct?

Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :

---

I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )

I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.

I wrap the cmd socket like:

self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')

Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...

self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')

wrap the data connection with SSL:

ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)

than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?

def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()


what could be reason? 
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-26 14:14

Message:
Logged In: YES 
user_id=21627

This is now fixed in 50844. I won't backport it to 2.4, as
it may cause working code to fail. For example, httplib
would fail since it would already close the connection in
getresponse, when the response object should still be able
to read from the connection.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-03 14:03

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? It makes sure
_socketobject.close really closes the socket, rather than
relying on reference counting to close it.

--

Comment By: kxroberto (kxroberto)
Date: 2006-05-11 14:05

Message:
Logged In: YES 
user_id=972995

Testing it with Python2.5a2, the problem is still there.

Without the .shutdown(2) (or .shutdown(1)) patch to the
httplib.SharedSocket (base for FakeSocket), the ftps example
freezes on the cmd channel, because the SSL'ed data channel
doesn't close/terminate --> FTPS server doesn't respond on
the cmd channel. The ftps example is most specific to show
the bug. 

Yet you can also easily blow up a HTTPS-server with this
decent test code who only opens (bigger!) files and closes
without reading everything:

Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
Robert's Interactive Python - TAB=complete
import sys,os,re,string,time,glob,thread,pdb
>>> import urllib
>>> l=[]
>>> for i in range(10):
...f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz')
...f.close()
...l.append(f)
...
>>>


=> in the (apache) servers ssl_engine_log you can see that
connections remain open (until apache times out after 2
minutes) and lots of extra apache daemons are started!

=> f.close() doesn't really close the connection (until it
is __del__'ed )


Trying around I found that the original undeleted f.fp._ssl
is most probably the cause and holds the real socket open. 
a f.fp._sock.close() doesn't close also  - but only when del
f.fp._

[ python-Bugs-1512124 ] OSX: debugger hangs IDLE

[SourceForge.net]

Bugs item #1512124, was opened at 2006-06-25 15:45
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512124&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Tkinter
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Aahz (aahz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: OSX: debugger hangs IDLE

Initial Comment:
This has been previously found on 2.3/2.4 and verified again with 2.5b1
(was hoping that the 1.2 IDLE update would fix):

When you bring up the debugger window in IDLE on OSX, you'll notice that
it's vibrating, as if it's stuck in a resize loop.  Unless you
immediately resize the window manually, IDLE will hang the next time you
try to do something that updates the debugger window.


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 22:47

Message:
Logged In: YES 
user_id=580910

The vibration problem also occurs if you start idle with 'python idle.py -n'. 

I'm moving this to Tkinter. I'll see if I can extract a small program that 
shows the 
problem, I'm not exactly a Tkinter expert. I'm also unassigning this bug, 
there's 
little change that I'm going to fix this.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-24 19:23

Message:
Logged In: YES 
user_id=149084

Could you revert your fix locally and try running
w/o the subprocess?  If that fixes it you could
blame the rather elaborate communication between
the subprocess and the debugger gui, and it would
be good to check before blaming AquaTk.

If it's still there, maybe you could provide a cutdown
in Tkinter (w/o IDLE) and change the Category to 
Tkinter?

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-24 08:09

Message:
Logged In: YES 
user_id=580910

You'd have to test with a version of python before 2.5b1, after that I've added 
a 
workaround for this issue. This workaround makes the debugger window 
narrower than intended, but at least you have a working version of IDLE.

My guess is that the root cause of this issue is a bug in TkAqua. I haven't 
filed a 
bug with them because I have never programmed in Tcl and would therefore 
require lots of time to get a Tcl program going that demonstrates this problem.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-23 22:47

Message:
Logged In: YES 
user_id=149084

Please try running IDLE w/o the subprocess by
starting it with the -n switch.  Does the issue
still exist?

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-25 22:49

Message:
Logged In: YES 
user_id=580910

And when you do resize the window layout sucks, automatic layout seems to 
be buggy here (although I must admit that I haven't seen IDLE on other 
platforms).

I have no idea what is causing this bug. Upgrading the Tk version to the very 
latest instead of using the system version doesn't help.

I've checked in a workaround in revision 47091. That patch avoids explicitly 
sizing the stackviewer widget on OSX, which seems to fix this problem. The 
debugger window now is rather less wide than it was before, which means 
users will likely have to resize the window if they want to use the debugger.

I'm leaving this bug open and unassign it in the hope that someone who 
actually knows Tkinter proposed a better fix.

--

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

[ python-Bugs-1526585 ] Concatenation on a long string breaks

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Armin Rigo (arigo)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

[EMAIL PROTECTED]:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 08:50

Message:
Logged In: YES 
user_id=33168

You're correct that bigmem is primarily for testing
int/Py_ssize_t.  But it doesn't have to be.  It has support
for machines with largish amounts of memory (and limiting
test runs).  I didn't know where else to put such a test.  I
agree that this bug would only occur on 32-bit platforms. 
Most machines can't run it, so about the only other option I
can think of would be to put it in it's own file and add a
-u option.  That seemed like even more work.

I'm not tied to bigmem at all, but it would be nice to have
a test for this somewhere.  I'm sure there are a bunch of
other places we have this sort of overflow and it would be
good to test them somewhere.  Do whatever you think is best.

--

Comment By: Armin Rigo (arigo)
Date: 2006-07-26 02:01

Message:
Logged In: YES 
user_id=4771

I'm unsure about how the bigmem tests should be used.
I think that I am not supposed to set a >2G limit on
a 32-bit machine, right?  When I do, I get 9 failures:
8 OverflowErrors and a stranger AssertionError in
test_hash.  I think that these tests are meant to
test the int/Py_ssize_t difference on 64-bit 
machines instead.  The bug this tracker is about
only shows up on 32-bit machines.

My concern is that if we add a test for the current
bug in test_bigmem, then with a memory limit < 2GB
the test is essentially skipped, and with a memory
limit > 2GB then 9 other tests fail anyway.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:19

Message:
Logged In: YES 
user_id=33168

Armin, can you check in your patch and backport?  Also a
news entry and a test in test_bigmem would be great. 
Thanks.  If not let me know (assign to me) and I'll finish
this up.

This fix should be backported as well.

--

Comment By: Jp Calderone (kuran)
Date: 2006-07-25 13:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


--

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 11:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-24 20:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
> Py_ssize_t new_len = v_len + w_len;
> if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 20:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

  Py_ssize_t new_len = v_len + w_len;
  if (new_len < 0) {

Jp, can

[ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10

[SourceForge.net]

Bugs item #1528620, was opened at 2006-07-25 22:34
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=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

--

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

[ python-Bugs-1525469 ] SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Warren (qopit)
>Assigned to: A.M. Kuchling (akuchling)
Summary: SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type

Initial Comment:
Use of sys.exc_value and sys.exc_type is not thread
safe.  It should just use sys.exc_info.

Both exc_value and exc_type are used in two exceptiuon
trapping locations.

This goes back to at least 2.3, and I've checked 2.5
svn ver 50569 and it is still an issue.

Russ


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 13:45

Message:
Logged In: YES 
user_id=11375

Tested patch attached.  I want to get the go-ahead from the
release manager before committing this change.


--

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

[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE shell window gets very slow when displaying long lines

Initial Comment:
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 
mydictionary').

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 
better.

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
buglist.


--

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 20:56

Message:
Logged In: YES 
user_id=1330769

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 22:52

Message:
Logged In: YES 
user_id=149084

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 22:35

Message:
Logged In: YES 
user_id=341410

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).

--

Comment By: Heiko Selber (drhok)
Date: 2006-03-29 22:19

Message:
Logged In: YES 
user_id=865975

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.
Duh.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?


--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 01:08

Message:
Logged In: YES 
user_id=149084

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

What is your use case?  IDLE is designed to be an IDE.  Why 
output such massive data?

You may be interested in Squeezer, a Noam Raphael extension to 
IDLEfork.

http://sourceforge.net/tracker/index.php?
func=detail&aid=704316&group

[ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-25 21:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

--

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

[ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii

[SourceForge.net]

Bugs item #1501291, was opened at 2006-06-05 18:34
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii

Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:

$ cat test.py
import curses

screen = curses.initscr()

screen.addstr("\x80")

screen.getch()
curses.endwin()

$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR

This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier. 

To ensure that ncurses was able to display the
character, I wrote this test C program: 

$ cat test.c
#include 

int main()
{
initscr();
int rtn = addstr("\x80");
getch(); 
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}

$ gcc test.c -o test -lncurses
$ ./test

This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.  

I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.  

Can this be fixed in _cursesmodule.c?

--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 14:45

Message:
Logged In: YES 
user_id=11375

The ncurses 5.5 changelog, currently at
http://www.gnu.org/software/ncurses/ncurses.html, contains
this entry:

  * use setlocale() to query the program's current locale
rather than using getenv(). This supports applications which
rely upon legacy treatment of 8-bit characters when the
locale is not initialized.

So maybe this is a problem in ncurses 5.4 that can be
avoided if your Python script calls 'locale.setlocale("")'.


--

Comment By: UnixOps (unixops1234)
Date: 2006-06-08 16:02

Message:
Logged In: YES 
user_id=1534776

I tried recompiling Python with the patch from bug #1464056
that fixes the panelw linking in _curses_panel.so. It now
properly links with libpanelw instead of libpanel, but the
original problem persists. I still get "_curses.error:
addstr() returned ERR" when running the test code.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-08 13:58

Message:
Logged In: YES 
user_id=21627

I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.

--

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

[ python-Bugs-1528593 ] IDLE: printing issue on OSX

[SourceForge.net]

Bugs item #1528593, was opened at 2006-07-25 21:49
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=1528593&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.6
Status: Open
Resolution: None
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE: printing issue on OSX

Initial Comment:
The printing solution for IDLE on OSX is lacking a page setup dialog, or 
even a print dialog. This means output will also be sent to the default 
printer.

If there is no default printer (which means the user hasn't defined a 
printer at all) the user will get a confusing message (lpr failed). BTW. the 
message is clear for technical users, but not for mac users that aren't unix 
saffy.

It would be nice if IDLE could interface with the Carbon/Cocoa print 
system using a real print dialog. That way users can select another than 
the default printer, change page settings and can even print to PDF.

I've filed this as a low-priority issue for 2.6 because there's no way this 
will get into 2.5 and it likey non-trivial as well.

BTW. this might be a feature-request rather than a bug.

--

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

[ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10

[SourceForge.net]

Bugs item #1528620, was opened at 2006-07-25 22:34
Message generated for change (Settings changed) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528620&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

--

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

[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines

[SourceForge.net]

Bugs item #1442493, was opened at 2006-03-03 09:45
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.4
Status: Open
>Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE shell window gets very slow when displaying long lines

Initial Comment:
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 
mydictionary').

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 
better.

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
buglist.


--

>Comment By: Kurt B. Kaiser (kbk)
Date: 2006-07-26 16:38

Message:
Logged In: YES 
user_id=149084

Sure, please open a patch and supply a diff against
Noam's version.

--

Comment By: Tal Einat (taleinat)
Date: 2006-07-26 13:56

Message:
Logged In: YES 
user_id=1330769

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.

--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-29 15:52

Message:
Logged In: YES 
user_id=149084

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 15:35

Message:
Logged In: YES 
user_id=341410

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).

--

Comment By: Heiko Selber (drhok)
Date: 2006-03-29 15:19

Message:
Logged In: YES 
user_id=865975

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.
Duh.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?


--

Comment By: Kurt B. Kaiser (kbk)
Date: 2006-03-28 18:08

Message:
Logged In: YES 
user_id=149084

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

W

[ python-Bugs-1529269 ] Python 2.5b2 fails to build (GCC) on Solaris 10

[SourceForge.net]

Bugs item #1529269, was opened at 2006-07-26 23:17
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=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build (GCC) on Solaris 10

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

--

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

[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[SourceForge.net]

Bugs item #1529269, was opened at 2006-07-26 23:17
Message generated for change (Settings changed) made by ostkamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

Initial Comment:
Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol : offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function `PyCursesWindow_
GetStr':
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822:
warning: implicit declar
ation of function `mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
 _curses
running build_scripts

Regards,

Guido

--

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

[ python-Bugs-1529297 ] unrelated variable messing up doctests

[SourceForge.net]

Bugs item #1529297, was opened at 2006-07-26 15:02
Message generated for change (Settings changed) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529297&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
>Summary: unrelated variable messing up doctests

Initial Comment:
Version 2.5b2 with IDLE 1.2b2 running on Windows XP 
Home, fully updated.

Unpack the attached zip file.
Open program.py, test_suite.py, in separate IDLE 
windows.  
Run test_suite.py.  
  8 passed and 0 failed.
Now add a variable at the top of program.py, any name 
will do.
  xyz = 2
Re-run test_suite.py.  
  7 passed and 1 failed !!

I haven't been able to isolate the problem, but it is 
repeatable.  Taking out blocks of unrelated statements 
changes the behavior.  Feels like a memory allocation 
error, or something strange.


--

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

[ python-Bugs-1516068 ] Under OS X, compiling against local readline fails

[SourceForge.net]

Bugs item #1516068, was opened at 2006-07-03 02:42
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516068&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nelson Arzola (narzola72)
Assigned to: Nobody/Anonymous (nobody)
Summary: Under OS X, compiling against local readline fails

Initial Comment:
I've installed a version of the GNU Readline (5.1) in a
local directory (/Volumes/DATA/dev/toolset/{include,lib}.

I'm compiling Python with:

CFLAGS=-I/Volumes/DATA/dev/toolset/include \
LDFLAGS=-L/Volumes/DATA/dev/toolset/lib \
./configure \
 --prefix=/Volues/DATA/dev/toolset/inst/python \
 --with-libs="-lexpat -lncurses -lreadline"
make

I get the following error:

./Modules/readline.c:885: error: 'HISTORY_STATE'
undeclared (first use in this function)
./Modules/readline.c:885: error: 'state' undeclared
(first use in this function)
./Modules/readline.c:887: warning: assignment discards
qualifiers from pointer target type

When I look at the gcc command that was used to compile
Modules/readline.c, I see that my CFLAGS is not passed
to gcc and so the (broken) system readline is being used.

I can temporarily solve this problem with:

echo "readline readline.c ${CFLAGS} ${LDFLAGS}
-lreadline -l termcap" >> Modules/Setup.local

before I call make.

What I can't understand is why the build process
correctly uses the local version of expat (2.0.0) that
is installed in the directories with readline, but not
readline?

--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 22:52

Message:
Logged In: YES 
user_id=580910

I think this is fixed in python2.5, could you verify that?

I've applied a patch to setup.py a while back that makes it use -I and -L flags 
that in LDFLAGS/CFLAGS during the build of python (on osx only).

I'm building 2.5 with a local installation of readline (and several other 
libraries) 
and that works fine. 2.4 also works for me, but my 2.4 tree contains a number 
of patches that might affect this issue.

--

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-06 12:06

Message:
Logged In: YES 
user_id=1478788

I also included the complete session build log because I can
see that the CFLAGS and LDFLAGS are being passed through at
least some of the time.  Hope this all helps.

--

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-06 12:04

Message:
Logged In: YES 
user_id=1478788

I redid my build, and I can confirm that the build process
picked up the correct version of expat and will not pick up
the correct version of readline without the fix labeled above.

I've included my config.log because I think it might help
you -- atleast you can see the various settings that I had
in place.

Here is the output of otool -L:

CWD> /Volumes/DATA/dev/toolset/bin 
[EMAIL PROTECTED] 133> ./python
Python 2.4.3 (#1, Jul  6 2006, 02:42:44) 
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> 
CWD> /Volumes/DATA/dev/toolset/bin 
[EMAIL PROTECTED] 134> otool -L python
python:
   
/Volumes/DATA/dev/toolset/inst/expat/lib/libexpat.1.dylib
(compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version
5.4.0, current version 5.4.0)
   
/Volumes/DATA/dev/toolset/inst/readline/lib/libreadline.5.1.dylib
(compatibility version 5.0.0, current version 5.1.0)
/usr/lib/libSystem.B.dylib (compatibility version
1.0.0, current version 88.1.6)
/usr/lib/libstdc++.6.dylib (compatibility version
7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version
1.0.0, current version 1.0.0)
CWD> /Volumes/DATA/dev/toolset/bin 
[EMAIL PROTECTED] 135> 

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-06 10:22

Message:
Logged In: YES 
user_id=580910

Are you sure it picks up the copy of expat you expect it to use?

I fixed this issue (CFLAGS being ignored) for python 2.5 (on the mac only).

BTW. You should use "OPT" instead of "CFLAGS" to pass additional compiler 
flags, IIRC the latter is replaced completely by the configure script.

--

Comment By: Nelson Arzola (narzola72)
Date: 2006-07-03 02:44

Message:
Logged In: YES 
user_id=1478788

Sorry, I forgot to mention that I'm using the latest verion
of Python 2.4.3 from python.org.

---

[ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result

[SourceForge.net]

Bugs item #1528074, was opened at 2006-07-24 19:59
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Machin (sjmachin)
>Assigned to: Tim Peters (tim_one)
Summary: difflib.SequenceMatcher.find_longest_match()  wrong result

Initial Comment:
A short example script is attached.
Two strings, each 500 bytes long. Longest match is the
first 32 bytes of each string. Result produced is a
10-byte match later in the string.

If one byte is chopped off the end of each string (len
now 499 each), the correct result is produced.

Other observations, none of which may be relevant:
1. Problem may be in the heuristic for "popular"
elements in the __chain_b method. In this particular
example, the character '0' (which has frequency of 6 in
the "b" string) is not "popular" with a len of 500 but
is "popular" with a len of 499.
2. '0' is the last byte of the correct longest match.
3. The correct longest match is at the start of the
each of the strings.
4. Disabling the "popular" heuristic (like below)
appears to make the problem go away:

if 0:
# if n >= 200 and len(indices) * 100 > n:
populardict[elt] = 1
del indices[:]
else:
indices.append(i)
5. The callable self.isbpopular is created but appears
to be unused.
6. The determination of "popular" doesn't accord with
the comments, which say 1%. However with len==500,
takes 6 to be popular.

--

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

[ python-Bugs-1528620 ] Python 2.5b2 fails to build on Solaris 10

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido Ostkamp (ostkamp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5b2 fails to build on Solaris 10

Initial Comment:
Hello,

I tried to build Python 2.5b2 on Solaris 10 with the
Sun Workshop Compiler, which fails.

Please see the attachment for a complete log in several
stages. Here is a short summary:

*
build/temp.solaris-2.10-sun4us-2.5/libffi/include/ffi.h
contains illegal C-syntax __attribute(...)

This might be legal for GCC, but not for other compilers. 

* Even if this is removed, there are other fatal
compiler errors in the _ctypes module later on.

* The build process seems to invoke _cursesmodule.c.
This contains the use of a function  mvwgetnstr(). This
function does not exist in /usr/lib/libcurses.so.

* The build process fails to link with libcurses.so.

The Python 2.4.3 release fails for the same reasons
regarding the curses problems, but the _ctypes stuff
did not exist in this form. 

I would appreciate, if these bugs could be fixed.

Regards,

Guido

--

>Comment By: Guido Ostkamp (ostkamp)
Date: 2006-07-26 22:52

Message:
Logged In: YES 
user_id=1028306

Hello,

@nnorwitz:

Unfortunately I cannot provide a patch, but can give some hints:

If you (or the developers) have a Solaris 10 box, they can
download the Sun Studio 11 which includes the Sun Compiler
for free from the URL:


Then you should be able to verify the problems yourself
(though I am using an older version of the compiler from the
times when it was commercial).

Regarding the _ctypes module problems:

The module contains a libffi which nowadays appears to be
part of the GNU GCC. This lib was never made to work with
anything else but GCC, as it seems. Even older versions do
not compile.

Therefore, if this module is not really necessary, it should
be removed or at least deactivated by the configuration if
not using GCC. It also seems, that other modules like
_struct appear to be depending on this, if I'm right.

Regarding the curses problem:

I can workaround this if changing the mvwgetnstr() to
mvwgetstr() with omitting the last parameter. However this
should be configured automatically.

Futhermore there was no linking of the correct library
(/usr/lib/libcurses.so). I had to activate the curses entry
in Modules/Setup manually and to call make two more times. 

Regarding GCC on Solaris: I tried with GCC but it failed on
Solaris 10 as well. I will open a new fault report for the
GCC problems.

@akuchling:

You say the curses bug should be fixed in 2.4 and 2.5. It
isn't. I tried 2.4.3 yesterday as well and ran into the very
same problem. Or do you mean it was changed more recently?



--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 19:28

Message:
Logged In: YES 
user_id=11375

The _cursesmodule mvwgetnstr() problem was reported as bug
#1471938 and should now be fixed on both the 2.4 and 2.5
branches.



--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 06:11

Message:
Logged In: YES 
user_id=33168

Can you provide a patch to address these problems?

I don't know that any developers have access to the sun
workshop compiler.  We have a Solaris 10 box, but it only
has gcc AFAIK.

--

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

[ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1

[SourceForge.net]

Bugs item #1513611, was opened at 2006-06-27 14:06
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 20:31

Message:
Logged In: YES 
user_id=33168

I think Martin is of the same opinion.  This needs to be
resolved soon.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 20:03

Message:
Logged In: YES 
user_id=3066

I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.

While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time.  Given the release schedule,
it doesn't make sense to jump through those hoops.  The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used.  Moving to the "xmlcore" package
proved to be more than that hack could support.

I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package.  Further
investigation into a better approach can be made for Python 2.6.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 19:36

Message:
Logged In: YES 
user_id=3066

The patch attached contains the wrong bug number, but it
really is for this issue.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 19:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-07-10 00:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

--

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

[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: possible bug in mystrtol.c with recent gcc

Initial Comment:
python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2
fails test_unary_minus in test_compile.py. Some
investigating showed that the -ftree-vrp pass of that
gcc (implied by -O2) optimizes out the "result ==
-result" test on line 215 of PyOS_strtol, meaning
PyOS_strtol of the most negative long will incorrectly
overflow. 

Python deals with this in this case by constructing a
python long object instead of a python int object, so
at least in this case the problem is not serious. I
have no idea if there is a case where this is a "real"
problem.

At first I reported this as a gentoo compiler bug, but
got the reply that:

"""
I'm pretty sure it's broken. -LONG_MIN overflows when
LONG_MIN < -LONG_MAX, and in standard C as well as "GNU
C", behaviour after overflow on signed integer
operations is undefined.
"""

(see https://bugs.gentoo.org/show_bug.cgi?id=140133)

So now I'm reporting this here. There seems to be a
LONG_MIN constant in limits.h here that could checked
against instead, but I have absolutely no idea how
standard that is. Or this could be a compiler bug after
all, in which case I would appreciate information I Can
use to back that up :)

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-26 21:35

Message:
Logged In: YES 
user_id=33168

Tim's fix corrected the problem on amd64 gentoo linux with
gcc 4.1.1.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-26 18:16

Message:
Logged In: YES 
user_id=31435

Made a non-heroic effort to repair this in rev 50855, but
have no platform on which it could make any difference (and
apparently no Python buildbot test platform cares either) .
 Would be nice if someone who has such a platform could
check against current Python trunk.

--

Comment By: Nick Maclaren (nmm)
Date: 2006-07-17 02:20

Message:
Logged In: YES 
user_id=42444

Yes, this is a duplicate of 1521726.

The compiler people's answer is correct, and mystrtoul.c is
incorrect. LONG_MIN has been in C since C90, so should be
safe, but its value may not always be what you expect.

However, the code breakage is worse that just that test, and
there are the following 3 cases of undefined behaviour:

1) Casting and unsigned long to long above LONG_MAX.
2) That test.
3) result = -result.

The fix should be to make result unsigned long, and check
the range BEFORE any conversion.  Nothing else is safe.

It is a matter of taste whether to include a fiddle for the
number that can be held only when negated - I wouldn't, and
would let that number be converted to a Python long, but
others might disagree.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13

Message:
Logged In: YES 
user_id=33168

Is this a duplicate of 1521726?

--

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

[ python-Bugs-1513611 ] xml.sax.ParseException weirdness in python 2.5b1

[SourceForge.net]

Bugs item #1513611, was opened at 2006-06-27 17:06
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1513611&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.ParseException weirdness in python 2.5b1

Initial Comment:
There is something weird going on with xml.sax
exceptions, probably related to the xml/xmlcore shuffle:

from xml.sax import make_parser, SAXParseException
from StringIO import StringIO

parser = make_parser()

try:
parser.parse(StringIO('invalid'))
except SAXParseException:
print 'caught it!'

On python 2.4.3 this prints "caught it!". On python
2.5b1 the exception is not caught, because it is a
different  exception: an
xmlcore.sax._exceptions.SAXParseException. Printing the
SAXParseException imported from xml.sax gives "".

Stumbled on this running the logilab-common (see
logilab.org) tests with python 2.5b1, but it seems
likely other code will be affected.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 23:03

Message:
Logged In: YES 
user_id=3066

I've managed to come up with a patch that solves this
specific issue, but it really deals with the symptom and not
the real problems.

While I think the "xmlcore" package was the right idea, I'm
not convinced it can be correctly implemented without
enormous effort at this time.  Given the release schedule,
it doesn't make sense to jump through those hoops.  The
previous hackery that made allowed the PyXML distribution to
"replace" the standard library version of the "xml" package
worked only because there was only one public name for
whichever was being used.  Moving to the "xmlcore" package
proved to be more than that hack could support.

I think the right thing to do for Python 2.5 is to revert
the changes that added the "xmlcore" package.  Further
investigation into a better approach can be made for Python 2.6.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:36

Message:
Logged In: YES 
user_id=3066

The patch attached contains the wrong bug number, but it
really is for this issue.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-26 22:01

Message:
Logged In: YES 
user_id=3066

Patch #1519796 does not do anything for this, based on the
current trunk.  I've attached a diff containing a test case.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-07-10 03:37

Message:
Logged In: YES 
user_id=1326842

This bug is simmilar to http://python.org/sf/1511497.
It is caused by absolute imports in xmlcore.sax.expatreader.
Patch #1519796 ( http://python.org/sf/1519796 )
should fix it.

--

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

[ python-Bugs-1526585 ] Concatenation on a long string breaks

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenation on a long string breaks

Initial Comment:
Consider this transcript:

[EMAIL PROTECTED]:~/Projects/python/trunk$ ./python
Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> x = 'x' * (2 ** 31 - 1)
>>> x = x + 'x'
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/stringobject.c:4103: bad argument
to internal function
>>> len(x)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'x' is not defined
>>> 


I would expect some exception other than SystemError
and for the locals namespace to not become corrupted.


--

>Comment By: Jp Calderone (kuran)
Date: 2006-07-25 16:06

Message:
Logged In: YES 
user_id=366566

Tested Armin's patch, looks like it addresses the issue. 
One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x')
fails the same way ('x' * (2 ** 32 - 1) + 'x').  Don't
really understand why, just thought I'd mention it.


--

Comment By: Armin Rigo (arigo)
Date: 2006-07-25 14:25

Message:
Logged In: YES 
user_id=4771

The check should be done before the variable is removed
from the namespace, so that 'x' doesn't just disappear.
Attached a patch that does this.  Also, let's produce
an exception consistent with what PyString_Concat()
raises in the same case, which is an OverflowError
instead of a MemoryError.

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-24 23:57

Message:
Logged In: YES 
user_id=31435

[Neal]
>  Tim since we know both lens are >= 0, is this test
> sufficient for verifying overflow:
>
> Py_ssize_t new_len = v_len + w_len;
> if (new_len < 0) {

Right!  That's all the new checking needed in
string_concatenate().

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-24 23:46

Message:
Logged In: YES 
user_id=33168

Attached a patch against 2.5.  The patch should work against
2.4 too, but you will need to change all Py_ssize_t to int.
 Tim since we know both lens are >= 0, is this test
sufficient for verifying overflow:

  Py_ssize_t new_len = v_len + w_len;
  if (new_len < 0) {

Jp, can you test the patch?

--

Comment By: Tim Peters (tim_one)
Date: 2006-07-22 10:11

Message:
Logged In: YES 
user_id=31435

Part of the problem appears to be that ceval.c's
string_concatenate() doesn't check for overflow in the
second argument here:

if (_PyString_Resize(&v, v_len + w_len) != 0)

The Windows malloc on my box returns NULL (and so Python
raises MemoryError) on the initial:

x = 'x' * (2 ** 31 - 1)

attempt, so I never get that far.  I'm afraid this is
muddier in strange ways on Linux because the Linux malloc()
is pathologically optimistic (can return a non-NULL value
pointing at "memory" that can't actually be used for anything).

--

Comment By: Michael Hudson (mwh)
Date: 2006-07-22 05:00

Message:
Logged In: YES 
user_id=6656

Confirmed with 2.4.  Ouch.

--

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

[ python-Bugs-1257728 ] error message incorrectly claims Visual C++ is required

[SourceForge.net]

Bugs item #1257728, was opened at 2005-08-12 15:28
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: error message incorrectly claims Visual C++ is required

Initial Comment:
Thank you for the excellent distutils tool!

Two problems:

First, this error message is emitted on win32, but it
appears to be incorrect, inasmuch as the Microsoft
compiler is not actually required:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with the same
version of the compiler, but it isn't installed.
Error: Subprocess exited with result 1 for project core
"""

Second, the usage of distutils is somewhat confusing,
as the following line emits that error message:

./setup.py build -c mingw32; ./setup.py install

but the following line, which I intuitively believed to
be equivalent at first, works to compile and install
the package:

./setup.py build -c mingw32 install

--

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-07-25 21:10

Message:
Logged In: YES 
user_id=52562

How about:

"""
error: Python was built with version 7.1 of Visual
Studio, and extensions need to be built with a compiler that
can generate compatible binaries.  Some versions of gcc can
produce compatible binaries if given the "-mno-cygwin" flag.
 Distutils will pass the "-mno-cygwin" flag to gcc if
distutils is given the "-c mingw32" flag to the "build" command.

Error: Subprocess exited with result 1 for project core
"""

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-24 13:00

Message:
Logged In: YES 
user_id=21627

What would you like to say the error message instead?

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2006-03-31 11:35

Message:
Logged In: YES 
user_id=52562

Changing this from category Distutils to category Windows.

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-11-23 18:51

Message:
Logged In: YES 
user_id=52562

Whoo!  Progress!  Now it no longer spuriously claims that
Visual C++ is required for building extensions for Python,
and instead it spuriously claims that the .NET SDK is
required for building extensions for Python!

"""
error: The .NET Framework SDK needs to be installed before
building extensions for Python.
"""

--

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