[ python-Bugs-1689458 ] pdb unable to jump to first statement

2007-03-31 Thread SourceForge.net
Bugs item #1689458, was opened at 2007-03-27 17:07
Message generated for change (Comment added) made by rockyb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gotgenes (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

Comment By: Rocky Bernstein (rockyb)
Date: 2007-03-31 06:32

Message:
Logged In: YES 
user_id=158581
Originator: NO

Although a single file unit test would be nice, below is a short simple
program that I think clearly shows the bug. Alas, as a follow-up comment I
don't see a way to attach files so I have to paste it inline. However with
this example and the information from Duncan Booth, I think the problem and
how to fix it is pretty clear.

file: jumpbug.py

#!/usr/bin/env python
import inspect, linecache, sys
def tracer(frame, event, arg):
global z
(filename, line_no) = inspect.getframeinfo(frame)[0:2]
print "Event %s at line %d:" % (event, line_no)
print "\t", linecache.getline(filename, line_no),
print "--"
try: 
if z == 0:
if line_no == 4:
print "***We jumped back to line 4 but should have gone to
2**"
sys.exit(1)
frame.f_lineno = 2 # And 3 is broken too.
except NameError:
pass
return tracer # This helps emacs figure indentation out
sys.settrace(tracer)
execfile("jumpbug2.py")
#END first file

file jumpbug2.py:

#!/usr/bin/env python
x = 2  # This statement gets skipped the 2nd time around
q = 1  # This statement gets skipped too!
try:   # tracer() will exit here if z == 0 and line_no == 4
y = z   
except NameError:
z = 0
print "When tracing via tracer(), f_lineno will be set to 2 here."
print "You should never get here when tracing"


file jumpbug2.py:

--

Comment By: gotgenes (gotgenes)
Date: 2007-03-28 21:24

Message:
Logged In: YES 
user_id=1180453
Originator: YES

Truthfully, I don't have enough know-how to write a full test case or a
patch. I have put forth a request on the comp.lang.python thread (link in
original report) for those that would to please do so.


[ python-Bugs-1622664 ] language reference index links are broken

2007-03-31 Thread SourceForge.net
Bugs item #1622664, was opened at 2006-12-26 22:15
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: language reference index links are broken

Initial Comment:
http://docs.python.org/ref/genindex.html

For example, this text "globals() (built-in function)" links to 
http://docs.python.org/ref/exec.html#l2h-571, which is completely wrong.

Some links are correct, but many others are broken.

The page footer says "Release 2.5, documentation updated on 19th September, 
2006."


--

>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 09:05

Message:
Logged In: YES 
user_id=752496
Originator: NO

Where do you think it should point to?

Take note that you're looking into the language reference, not the library
reference.

Regards,

--

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



[ python-Bugs-920573 ] http libraries throw errors internally

2007-03-31 Thread SourceForge.net
Bugs item #920573, was opened at 2004-03-21 15:16
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&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: Rejected
Priority: 5
Private: No
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: http libraries throw errors internally

Initial Comment:
Here's an error which someone just got running BitTorrent -

Exception in thread Thread-2:
 Traceback (most recent call last):
   File "/usr/lib/python2.3/threading.py", line 436, in
__bootstrap
 self.run()
   File "/usr/lib/python2.3/threading.py", line 416, in run
 self.__target(*self.__args, **self.__kwargs)
   File
"/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py",
line 72, in rerequest
 h = urlopen(url)
   File "/usr/lib/python2.3/urllib2.py", line 129, in
urlopen
 return _opener.open(url, data)
   File "/usr/lib/python2.3/urllib2.py", line 326, in open
 '_open', req)
   File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
 result = func(*args)
   File "/usr/lib/python2.3/urllib2.py", line 491, in

 lambda r, proxy=url, type=type,
meth=self.proxy_open: \
   File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
 if '@' in host:
 TypeError: iterable argument required

And here's one which people have been getting
*forever*, without it ever having been fixed (I've been
simply catching and ignoring it) -

Exception in thread Thread-60:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
apply(self.__target, self.__args, self.__kwargs)
  File "/home/zkessin/bin/BitTorrent/Rerequester.py",
line 85, in
rerequest
r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1140, in read
assert not self._line_consumed and self._line_left
AssertionError

Both of the above were caused by very straightforward
calls to httplib. I'm fairly certain (especially with
the second one) that they're internal bugs.

I'd like to mention while I'm at it that I'm extremely
unhappy with httplib. It's buggy, blocking, and doesn't
even support timeouts. While it's good to have a
library which supports all the vagaries of http, it
would be far better for it to be a simple object which
you tell when data  was received and it tells you when
there's data to be sent out. That way it could
integrate easily into other applications's event loops.
The blocking and buggy nature of httplib has caused me
no end of headaches, and I think I'm not the only one.

--

>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 09:09

Message:
Logged In: YES 
user_id=752496
Originator: NO

For any bug to be solved, we'd need a way to reproduce it.

Thes three points are very useful:

- What do you do
- What do you get
- What do you expect

"this is an error from somebody running bittorrent" is not specific enough
to us to be able to find the bug (if any).

Please, consider detail this a bit more.

Regards,

--

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



[ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified".

2007-03-31 Thread SourceForge.net
Bugs item #1623153, was opened at 2006-12-27 18:18
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
>Assigned to: Facundo Batista (facundobatista)
Summary: preferred diff format should be mentioned as "unified".

Initial Comment:

The page at http://www.python.org/dev/tools/ mentions that context diffs are 
preferred. However, the link at http://www.python.org/dev/patches/ mentions 
that "We like unified diffs. We grudgingly accept contextual diffs.". So 
"tools" page should preferably mention unified diffs as well.

Thanks,
Raghu

--

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



[ python-Bugs-1430435 ] urllib2 has memory leaks

2007-03-31 Thread SourceForge.net
Bugs item #1430435, was opened at 2006-02-13 01:30
Message generated for change (Comment added) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430435&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: halfik (halfik)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 has memory leaks

Initial Comment:
reg = urllib2.Request(url, data, headers)
rl_handle = urllib2.urlopen(reg)

urllib2 has hot memory leaks.

gc: uncollectable <_fileobject memory_adres>
gc: uncollectable 


--

>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 09:36

Message:
Logged In: YES 
user_id=752496
Originator: NO

How did you produce those results? (how can I reproduce them?)

In which Python version you did?

Regards,

--

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



[ python-Bugs-1379209 ] socket.recv(OOB) raises exception on closed socket

2007-03-31 Thread SourceForge.net
Bugs item #1379209, was opened at 2005-12-13 00:14
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roy Smith (roysmith)
>Assigned to: Facundo Batista (facundobatista)
Summary: socket.recv(OOB) raises exception on closed socket

Initial Comment:
frame:pyClient$ python
Python 2.4.1 (#1, Aug 16 2005, 20:11:22) 
[GCC 3.4.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
frame:pyClient$ uname -a
SunOS frame 5.8 Generic_108528-27 sun4u sparc

If you try to read out-of-band data on a closed socket, the recv() call 
raises socket.error, signaling "invalid argument".  This seems wrong.  
Doing a normal (in-band) recv() on a closed socket returns an empty 
string; trying to read OOB data should do the same thing.

At worst, it should raise a more specific error.  I'm guessing this 
exception is reflecting an errno of EBADF.  A more specific error would 
at least make it clear that it's the first argument to recv() which was 
bad, not the second.

frame:pyClient$ cat oob.py
#!/usr/bin/env python

import socket

s = socket.socket()
s.connect (("localhost", 13))  # 13 = daytime
print "==> ", `s.recv(1024)`
print "OOB: ", `s.recv (1024, socket.MSG_OOB)`

frame:pyClient$ ./oob.py
==>  'Mon Dec 12 22:00:29 2005\n\r'
OOB: 
Traceback (most recent call last):
  File "./oob.py", line 8, in ?
print "OOB: ", `s.recv (1024, socket.MSG_OOB)`
socket.error: (22, 'Invalid argument')
frame:pyClient$ 


--

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



[ python-Bugs-1671676 ] test_mailbox is hanging while doing gmake test on HP-UX v3

2007-03-31 Thread SourceForge.net
Bugs item #1671676, was opened at 2007-03-01 19:24
Message generated for change (Comment added) made by shashikala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671676&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: Threads
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_mailbox is hanging while doing gmake test on HP-UX v3

Initial Comment:

 Hi ,

  I am testing Python 2.5 on HP-UX 11iv3 using gmake test , while testing the 
test  test_mailbox.py is hanging . 

  when tried to track the problem i came to know that
in the function 
  if pid == 0:
# In the child, lock the mailbox.
self._box.lock()
time.sleep(2)
self._box.unlock()
os._exit(0)

# In the parent, sleep a bit to give the child time to acquire
# the lock.
time.sleep(0.5)
try:
self.assertRaises(mailbox.ExternalClashError,
  self._box.lock)
finally:
# Wait for child to exit.  Locking should now succeed.
exited_pid, status = os.waitpid(pid, 0)

 after forking the child , child is not returning status to the parent while 
its waiting for the return status. 

  which part of the Python functionality is checked. 
 
   Please assist me to solve this.

Thanks in advance ,
shashi

 

--

>Comment By: shashi (shashikala)
Date: 2007-03-31 20:27

Message:
Logged In: YES 
user_id=1506183
Originator: YES

please find attached log stacktrace of test_mailbox.py , assist me to
analyse the test hang.
File Added: python.txt

--

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



[ python-Bugs-1688393 ] sock.recvfrom(-24) crashes

2007-03-31 Thread SourceForge.net
Bugs item #1688393, was opened at 2007-03-26 07:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1688393&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andrew Bennetts (spiv)
Assigned to: Facundo Batista (facundobatista)
Summary: sock.recvfrom(-24) crashes

Initial Comment:
Actually sock.recvfrom(x) crashes or causes memory corruption for all values in 
-sizeof(PyStringObject) <= x < 0, I think.

This script demonstrates the problem:

import socket, sys
s1 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s1.bind(('127.0.0.1', ))
s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s2.sendto('fdsjkldsfkj', ('127.0.0.1', ))
print s1.recvfrom(-24)

Try e.g. -1 instead of -24 as well.

I'm attaching a patch that fixes this bug, and adds a simple test for it too.

Other sock_recv* functions in socketmodule.c seem to already catch negative 
recvlen values and raise ValueError, but for some reason recvfrom missed out.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-31 11:57

Message:
Logged In: YES 
user_id=33168
Originator: NO

Committed revision 54635. (2.5)

2.6 fix was in 54594.

Also fixed some other copy and paste errors wrt method names when parsing
arguments.

--

Comment By: Facundo Batista (facundobatista)
Date: 2007-03-27 20:46

Message:
Logged In: YES 
user_id=752496
Originator: NO

Applied this to the trunk, let's see if we should backport it to 2.5.x
before close this bug.

--

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



[ python-Bugs-1655392 ] thirdparty extensions, --enable-shared, static linking

2007-03-31 Thread SourceForge.net
Bugs item #1655392, was opened at 2007-02-08 17:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655392&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Georg Brandl (gbrandl)
Summary: thirdparty extensions, --enable-shared, static linking

Initial Comment:
(I'm filing this under the "Build" category which may not be entirely accurate, 
but couldn't find a closer match. Is there a description of what the categories 
mean somewhere?).

Python 2.5 built with --enable-shared on linux produces a shared 
libpython2.5.so in the "normal" libdir and only a static libpython2.5.a in 
/usr/lib/python2.5/config. Normally when you build extensions you want them to 
link to the dynamic one. However python-config --ldflags has 
-L/usr/lib/python2.5/config in its output, causing build processes using it to 
prefer the static library over the dynamic one.

This is somewhat similar to bug 1600860: distutils does the same thing when 
compiling extensions in an --enable-shared python 2.5.

I think either python-config should be modified to not mention that "config" 
dir on an --enable-shared build or the build process should be modified to put 
a .so file next to the .a file in that directory.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-31 18:58

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in rev. 54634, 54636.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-09 12:46

Message:
Logged In: YES 
user_id=21627
Originator: NO

The categories aren't described anywhere.

python-config should describe the installed code; we shouldn't change what
gets installed how for 2.5.1.

Georg, with python-config being your code, can you take a look? If not,
please unassign (in which case I'd ask marienz whether he would like to
contribute a patch).

--

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



[ python-Bugs-920573 ] http libraries throw errors internally

2007-03-31 Thread SourceForge.net
Bugs item #920573, was opened at 2004-03-21 13:16
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&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
Private: No
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: http libraries throw errors internally

Initial Comment:
Here's an error which someone just got running BitTorrent -

Exception in thread Thread-2:
 Traceback (most recent call last):
   File "/usr/lib/python2.3/threading.py", line 436, in
__bootstrap
 self.run()
   File "/usr/lib/python2.3/threading.py", line 416, in run
 self.__target(*self.__args, **self.__kwargs)
   File
"/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py",
line 72, in rerequest
 h = urlopen(url)
   File "/usr/lib/python2.3/urllib2.py", line 129, in
urlopen
 return _opener.open(url, data)
   File "/usr/lib/python2.3/urllib2.py", line 326, in open
 '_open', req)
   File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
 result = func(*args)
   File "/usr/lib/python2.3/urllib2.py", line 491, in

 lambda r, proxy=url, type=type,
meth=self.proxy_open: \
   File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
 if '@' in host:
 TypeError: iterable argument required

And here's one which people have been getting
*forever*, without it ever having been fixed (I've been
simply catching and ignoring it) -

Exception in thread Thread-60:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
apply(self.__target, self.__args, self.__kwargs)
  File "/home/zkessin/bin/BitTorrent/Rerequester.py",
line 85, in
rerequest
r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1140, in read
assert not self._line_consumed and self._line_left
AssertionError

Both of the above were caused by very straightforward
calls to httplib. I'm fairly certain (especially with
the second one) that they're internal bugs.

I'd like to mention while I'm at it that I'm extremely
unhappy with httplib. It's buggy, blocking, and doesn't
even support timeouts. While it's good to have a
library which supports all the vagaries of http, it
would be far better for it to be a simple object which
you tell when data  was received and it tells you when
there's data to be sent out. That way it could
integrate easily into other applications's event loops.
The blocking and buggy nature of httplib has caused me
no end of headaches, and I think I'm not the only one.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-31 14:29

Message:
Logged In: YES 
user_id=80475
Originator: NO

Both of these still need to be looked at (whether or not Bram supplies
more detail).

--

Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 07:09

Message:
Logged In: YES 
user_id=752496
Originator: NO

For any bug to be solved, we'd need a way to reproduce it.

Thes three points are very useful:

- What do you do
- What do you get
- What do you expect

"this is an error from somebody running bittorrent" is not specific enough
to us to be able to find the bug (if any).

Please, consider detail this a bit more.

Regards,

--

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



[ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified".

2007-03-31 Thread SourceForge.net
Bugs item #1623153, was opened at 2006-12-27 16:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&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: Documentation
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Facundo Batista (facundobatista)
Summary: preferred diff format should be mentioned as "unified".

Initial Comment:

The page at http://www.python.org/dev/tools/ mentions that context diffs are 
preferred. However, the link at http://www.python.org/dev/patches/ mentions 
that "We like unified diffs. We grudgingly accept contextual diffs.". So 
"tools" page should preferably mention unified diffs as well.

Thanks,
Raghu

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-03-31 14:38

Message:
Logged In: YES 
user_id=80475
Originator: NO

I don't think we really do care.  Sometimes context diffs are easier to
understand and sometimes unified diffs are the way to go depending on the
patch.  I say, let the world do what the world will do.  No unnecessary
rules.

--

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



[ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2

2007-03-31 Thread SourceForge.net
Bugs item #1689617, was opened at 2007-03-27 21:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&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
Private: No
Submitted By: Michael Forbes (mforbes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Intel icc build fails with optimizations -O2

Initial Comment:
When building python 2.5 with the free Intel compilers for non-commercial use 
(icc), the build works without optimizations, but fails when optimizations -O2 
and -O3 are used.

The compilation proceedes without errors (though there are lot's of warnings 
and remarks) and makes a python executable, but when the python setup starts, 
the intepreter cannot import certain packages and cannot add two strings.

case $MAKEFLAGS in \
*-s*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 
-Ob2 -w1' ./python -E ./setup.py -q build;; \
*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 
-w1' ./python -E ./setup.py build;; \
esac
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in 
import sys, os, imp, re, optparse
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in 

import textwrap
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in 

import string, re
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in 
letters = lowercase + uppercase
SystemError: error return without exception set
make: *** [sharedmods] Error 1

For example:
$ ./python
'import site' failed; use -v for traceback
Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) 
[GCC Intel(R) C++ gcc 3.4 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "123"
>>> a + "12"
Traceback (most recent call last):
  File "", line 1, in 
SystemError: error return without exception set
>>> 

Note that both the import of the site file fails and the addition fails.

Python was configured with the following options:
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O2 -Ob2 -w1"

When compiled with fewer optimiztions, everything seems to work.
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O1 -Ob2 -w1"



--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-31 12:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

My guess is that it relates to strict aliasing (which Python violates). 
Can you find the equivalent flag to gcc's -fno-strict-aliasing in icc?

--

Comment By: Michael Forbes (mforbes)
Date: 2007-03-29 15:06

Message:
Logged In: YES 
user_id=253921
Originator: YES

I have spoken with some people who have had similar issues with the intel
compilers in other applications, so it looks like it might be a compiler
bug.  I will look into this.

Can anyone confirm this behaviour? (I only have access to one linux box).

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 04:32

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you debug this further to determine a specific problem? It could be a
compiler bug also, for all I can tell.

--

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



[ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2

2007-03-31 Thread SourceForge.net
Bugs item #1689617, was opened at 2007-03-28 04:26
Message generated for change (Comment added) made by mforbes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&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
Private: No
Submitted By: Michael Forbes (mforbes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Intel icc build fails with optimizations -O2

Initial Comment:
When building python 2.5 with the free Intel compilers for non-commercial use 
(icc), the build works without optimizations, but fails when optimizations -O2 
and -O3 are used.

The compilation proceedes without errors (though there are lot's of warnings 
and remarks) and makes a python executable, but when the python setup starts, 
the intepreter cannot import certain packages and cannot add two strings.

case $MAKEFLAGS in \
*-s*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 
-Ob2 -w1' ./python -E ./setup.py -q build;; \
*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 
-w1' ./python -E ./setup.py build;; \
esac
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in 
import sys, os, imp, re, optparse
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in 

import textwrap
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in 

import string, re
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in 
letters = lowercase + uppercase
SystemError: error return without exception set
make: *** [sharedmods] Error 1

For example:
$ ./python
'import site' failed; use -v for traceback
Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) 
[GCC Intel(R) C++ gcc 3.4 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "123"
>>> a + "12"
Traceback (most recent call last):
  File "", line 1, in 
SystemError: error return without exception set
>>> 

Note that both the import of the site file fails and the addition fails.

Python was configured with the following options:
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O2 -Ob2 -w1"

When compiled with fewer optimiztions, everything seems to work.
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O1 -Ob2 -w1"



--

>Comment By: Michael Forbes (mforbes)
Date: 2007-03-31 20:31

Message:
Logged In: YES 
user_id=253921
Originator: YES

It does not appear to be a problem with aliasing (icc accepts the
-fno-strict-aliasing flag and it is set by default using ./configure.  It
is another question of whether or not icc behaves this flag!).

This looks similar to a previous problem but I am not using any processor
specific optimizations:
http://mail.python.org/pipermail/python-list/2005-March/312145.html


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-31 19:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

My guess is that it relates to strict aliasing (which Python violates). 
Can you find the equivalent flag to gcc's -fno-strict-aliasing in icc?

--

Comment By: Michael Forbes (mforbes)
Date: 2007-03-29 22:06

Message:
Logged In: YES 
user_id=253921
Originator: YES

I have spoken with some people who have had similar issues with the intel
compilers in other applications, so it looks like it might be a compiler
bug.  I will look into this.

Can anyone confirm this behaviour? (I only have access to one linux box).

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-03-28 11:32

Message:
Logged In: YES 
user_id=21627
Originator: NO

Can you debug this further to determine a specific problem? It could be a
compiler bug also, for all I can tell.

--

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



[ python-Bugs-1689617 ] Intel icc build fails with optimizations -O2

2007-03-31 Thread SourceForge.net
Bugs item #1689617, was opened at 2007-03-28 04:26
Message generated for change (Comment added) made by mforbes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689617&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
Private: No
Submitted By: Michael Forbes (mforbes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Intel icc build fails with optimizations -O2

Initial Comment:
When building python 2.5 with the free Intel compilers for non-commercial use 
(icc), the build works without optimizations, but fails when optimizations -O2 
and -O3 are used.

The compilation proceedes without errors (though there are lot's of warnings 
and remarks) and makes a python executable, but when the python setup starts, 
the intepreter cannot import certain packages and cannot add two strings.

case $MAKEFLAGS in \
*-s*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 
-Ob2 -w1' ./python -E ./setup.py -q build;; \
*)  CC='icc -pthread' LDSHARED='icc -pthread -shared' OPT='-DNDEBUG -g -O2 -Ob2 
-w1' ./python -E ./setup.py build;; \
esac
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in 
import sys, os, imp, re, optparse
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/optparse.py", line 71, in 

import textwrap
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/textwrap.py", line 10, in 

import string, re
  File "/int/apps/mmf/src/Python-2.5_intel/Lib/string.py", line 26, in 
letters = lowercase + uppercase
SystemError: error return without exception set
make: *** [sharedmods] Error 1

For example:
$ ./python
'import site' failed; use -v for traceback
Python 2.5 (r25:51908, Mar 27 2007, 20:10:22) 
[GCC Intel(R) C++ gcc 3.4 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "123"
>>> a + "12"
Traceback (most recent call last):
  File "", line 1, in 
SystemError: error return without exception set
>>> 

Note that both the import of the site file fails and the addition fails.

Python was configured with the following options:
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O2 -Ob2 -w1"

When compiled with fewer optimiztions, everything seems to work.
./configure --with-gcc=icc\
--with-cxx-main=icc\
--prefix=/int/apps/mmf/apps/Python-2.5_intel/\
OPT="-g -O1 -Ob2 -w1"



--

>Comment By: Michael Forbes (mforbes)
Date: 2007-04-01 00:53

Message:
Logged In: YES 
user_id=253921
Originator: YES

I have narrowed the problem a bit to the file Python/ceval.c.  If you
build this manually without optimizations, then everything works fine
("make test" works).
icc -pthread -c -fno-strict-aliasing -DNDEBUG -g -w1 -O1 \
-I. -I./Include -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c

I have included the warnings the compiler spits out (but it spits out
similar warnings everywhere, so I doubt that these are the problem) and
attached the "optimization report".  I tried turning off as much as
possible (inlining, loop unrolling etc.) but could still not get it to
work.  There are some threads about loop unrolling issues with icc, but
these were for -O3 optimizations:

http://softwarecommunity.intel.com/isn/community/en-us/forums/thread/321812.aspx

If I compile with -O1 and -Ob1 then it breaks and I get the optimization
report attached.  The wierd thing is that if I use -O1 and -finline, I get
an empty optimization report and it works.  TFM states that "-finline [is
the] Same as -Ob1."  This at least is a compiler problem!  I suspect that
-Ob1 is doing more than just inlining (it looks that way from the report)
so I am not exactly sure where the problem is here yet.
 
icc -pthread -c -fno-strict-aliasing -DNDEBUG -g -Wall -O1\
 -Ob1 -opt-report -opt-report-level=max -opt-report-file=opt.rep.txt\
  -I. -I./Include   -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c

Python/ceval.c(198): remark #869: parameter "self" was never referenced
  PyEval_GetCallStats(PyObject *self)
^
Python/ceval.c(2710): remark #981: operands are evaluated in unspecified
order
PyString_AsString(keyword));
^
Python/ceval.c(2706): remark #981: operands are evaluated in unspecified
order
PyErr_Format(PyExc_TypeError,
^
Python/ceval.c(2722): remark #981: operands are evaluated in unspecified
order
 PyString_AsString(keyword));
  

[ python-Bugs-1622664 ] language reference index links are broken

2007-03-31 Thread SourceForge.net
Bugs item #1622664, was opened at 2006-12-26 16:15
Message generated for change (Comment added) made by drewp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&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: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: language reference index links are broken

Initial Comment:
http://docs.python.org/ref/genindex.html

For example, this text "globals() (built-in function)" links to 
http://docs.python.org/ref/exec.html#l2h-571, which is completely wrong.

Some links are correct, but many others are broken.

The page footer says "Release 2.5, documentation updated on 19th September, 
2006."


--

>Comment By: Drew Perttula (drewp)
Date: 2007-03-31 23:04

Message:
Logged In: YES 
user_id=127598
Originator: YES

Oh sorry, you're right. I was of course expecting
http://docs.python.org/lib/built-in-funcs.html#l2h-34 but that's in the
other doc section. 

Thanks for reviewing my report- ok to close.


--

Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 04:05

Message:
Logged In: YES 
user_id=752496
Originator: NO

Where do you think it should point to?

Take note that you're looking into the language reference, not the library
reference.

Regards,

--

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



[ python-Bugs-1622664 ] language reference index links are broken

2007-03-31 Thread SourceForge.net
Bugs item #1622664, was opened at 2006-12-27 01:15
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622664&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: Documentation
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: language reference index links are broken

Initial Comment:
http://docs.python.org/ref/genindex.html

For example, this text "globals() (built-in function)" links to 
http://docs.python.org/ref/exec.html#l2h-571, which is completely wrong.

Some links are correct, but many others are broken.

The page footer says "Release 2.5, documentation updated on 19th September, 
2006."


--

Comment By: Drew Perttula (drewp)
Date: 2007-04-01 07:04

Message:
Logged In: YES 
user_id=127598
Originator: YES

Oh sorry, you're right. I was of course expecting
http://docs.python.org/lib/built-in-funcs.html#l2h-34 but that's in the
other doc section. 

Thanks for reviewing my report- ok to close.


--

Comment By: Facundo Batista (facundobatista)
Date: 2007-03-31 12:05

Message:
Logged In: YES 
user_id=752496
Originator: NO

Where do you think it should point to?

Take note that you're looking into the language reference, not the library
reference.

Regards,

--

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