[ python-Bugs-1729277 ] SVNVERSION redefined during compilation

[SourceForge.net]

Bugs item #1729277, was opened at 2007-06-01 04:28
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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.6
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brett Cannon (bcannon)
Assigned to: Kristj�n Valur (krisvale)
Summary: SVNVERSION redefined during compilation

Initial Comment:
I sometimes get the following warning during a build:

./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined
:1:1: warning: this is the location of the previous definition


It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also 
passed in on the command-line in the Makefile when the module is built (line 
460).  I have no clue why this is being done.

--

Comment By: Kristj�n Valur (krisvale)
Date: 2007-06-08 01:58

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

Applied the patch in change 55821, and backported to 25-maint in 55822

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-05 19:23

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

Looks fine to me, please apply.

--

Comment By: Kristj�n Valur (krisvale)
Date: 2007-06-05 14:18

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

Here is a suggested patch.  I don't have a linux setup to test with this,
what do you think?
Oh, and sorry for messing this up, I thought subwcrev was used on all
platforms :(
File Added: woo.patch

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-05 09:50

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

The define is indeed needed on Windows. On a Windows installation, there
is typically no svnversion binary. However, TortoiseSVN ships with a
similar tool, calls subwcrev.exe, which does string interpolation on a
template file. So the define in getbuildinfo is the template, and the link
process creates a second C file (getbuildinfo1.c) which is then compiled
and linked into the interpreter. As subwcrev.exe might not be installed,
the build process used to pass a define SUBWCREV on the command line, which
was a condition to the definition of SVNVERSION. As Kristjan removed the
condition, the Unix build broke.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-06-04 23:30

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

I figure that much from my experiment.  What I am wondering is if the
#define in getbuildinfo.c is needed.  Does the Windows build need it?  Or
is it that just to guarantee that the file is self-supported and won't fail
to compile if the compile-time define is not passed in?

If the #define in the file is required then I vote for the #ifndef
solution with an explanation.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-04 21:58

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

SVNVERSION is passed on Unix. On Unix, there is no subwcrev program.
Instead, there is an svnversion program which computes the same string as
subwcrev, but prints it on stdout (rather than substituting it in some
template file).

Therefore, SVNVERSION needs to be passed on the command line.

--

Comment By: Brett Cannon (bcannon)
Date: 2007-06-04 21:41

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

Well, when I remove the command-line def (the entire -D argument when
building getbuildinfo.c) I get no subversion number out of sys.subversion. 
But when I comment out the SVNVERSION definition instead in getbuildinfo.c
I do have the subversion number show up.

And I just noticed that when both are defined I have no subversion number
(as is the case in the trunk at the moment).

I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef
and that fixed the problem.  but I don't know if doing that will just mask
an issue where SVNVERSION should not be defined in getbuildinfo.c at all if
it is being passed in during compilation.

--

Comment By: Kristj�n Valur (krisvale)
Date: 2007-06-04 11:46

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

The intent was to remove the reliance on the define SUBWCREV so to
simplify the actions of make_buildinfo.c.  It then only needs to either
copy it or run it through subwcrev.exe.  Now the code autodetects whether
it was passed through s

[ python-Bugs-1733943 ] Tkinter is not working on trunk (2.6)

[SourceForge.net]

Bugs item #1733943, was opened at 2007-06-09 04:35
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733943&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Tkinter is not working on trunk (2.6)

Initial Comment:
Hello. I tried to run tk app on trunk, I got following error.

///
// Code

import Tkinter as Tk
root = Tk.Tk()
label = Tk.Label(root, text="Test")
label.pack(fill=Tk.BOTH, expand=True)
root.mainloop()

///
// Error

Traceback (most recent call last):
  File "\debug.py", line 6, in 
label = Tk.Label(root, text="Test")
  File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 2464, in __init__
Widget.__init__(self, master, 'label', cnf, kw)
  File "e:\python-dev\trunk\lib\lib-tk\Tkinter.py", line 1930, in __init__
(widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: invalid command name "label .12893496 -text Test"


This is due to the change revision 55504 (Stop using METH_OLDARGS)

Currently, lib/lib-tk/Tkinter.py uses this convension

1929:self.tk.call(
1930:(widgetName, self._w) + extra + self._options(cnf))

...passing argument as single tuple. METH_OLDARGS treats this as same as 

self.tk.call(
widgetName, self._w, *(extra + self._options(cnf)))

So it was working, but now METH_VARARGS, it doesn't expand single tuple as 
arguments.

Maybe do we need to check all tk.call and apply patches like this?

Index: Lib/lib-tk/Tkinter.py
===
--- Lib/lib-tk/Tkinter.py   (revision 55836)
+++ Lib/lib-tk/Tkinter.py   (working copy)
@@ -1927,7 +1927,7 @@
 classes.append((k, cnf[k]))
 del cnf[k]
 self.tk.call(
-(widgetName, self._w) + extra + self._options(cnf))
+widgetName, self._w, *(extra + self._options(cnf)))
 for k, v in classes:
 k.configure(self, v)
 def destroy(self):

# Maybe already someone working on this?


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-06-09 07:40

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

Neal, you did that change...

--

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

[ python-Bugs-1732557 ] T_LONGLONG chokes on ints

[SourceForge.net]

Bugs item #1732557, was opened at 2007-06-07 06:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732557&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: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: T_LONGLONG chokes on ints

Initial Comment:
Structmember attributes defined as T_LONGLONG or T_ULONGLONG won't accept a 
plain int, and give a misleading error msg:

TypeError: bad argument type for built-in operation


--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-06-09 10:06

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

This is now fixed with said patch.

--

Comment By: Roger Upole (rupole)
Date: 2007-06-09 08:52

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

Submitted patch# 1733960


--

Comment By: Martin v. Löwis (loewis)
Date: 2007-06-08 19:54

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

Can you come up with a patch?

--

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

[ python-Bugs-1733757 ] RuntimeWarning: tp_compare didn't return -1 or -2

[SourceForge.net]

Bugs item #1733757, was opened at 2007-06-08 21:58
Message generated for change (Comment added) made by peaker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1733757&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
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: RuntimeWarning: tp_compare didn't return -1 or -2 

Initial Comment:
The code attached is giving the error below

D:\bin\Python251\Lib\threading.py:697: RuntimeWarning: tp_compare didn't return 
-1 or -2 for exception
  return _active[_get_ident()]
Exception exceptions.SystemError: 'error return without exception set' in 
 ignored
Ok, I have no clues why there could be an error here...




--

Comment By: Eyal Lotem (peaker)
Date: 2007-06-09 11:48

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

Bug #1733973 is related.

What is happening in this bug, is that tokenize.tokenize is using
generate_tokens to generate the tokens. Since tokeneater() fails while the
iteration is occuring, the exception is raised and it unwinds the
tokenize() call. This garbage collects the generate_tokens generator --
which throws a GeneratorExit into the generator.

This time, sysmodule.c's trace_trampoline is the one assuming it can
overwrite PyErr_*.

Maybe the correct way of fixing the bug is saving+clearing/restoring
PyErr_* in ceval.c:call_trace, rather than in each trace/profile handler.

The upside is that they all seem to assume that they can overwrite PyErr_*
and this will fix them all.
The downside is that the PyErr_* that's been set in the frame will not be
accessible to the trace function. This can be fixed by storing it in some
global.

Basically, the fix is to call PyErr_Fetch before the trace/profile func,
and PyErr_Restore after it. The problem is that the trace/profile func is a
function ptr in the PyThreadState that's used by more than Python's
ceval.c. It seems to be liberally used by pyexpat and others. This means
that this function pointer should always point at the wrapper function
rather than the given function, which means storing more information in the
thread state, and then extracting it from the thread state again.

This got more complicated and intricate than I intended, and the whole
thing has a wrong feel to it - as it seems to me that all calls to the
trace/profile func should be in one centralized place, and that place
should be wrapped.

I hope someone else will implement the fix or at least comment on this. If
anyone is not clear on what the fix is, please post questions (and if this
bug system has mailing notifications) and I'll further explain.

--

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

[ python-Bugs-1733986 ] mmap.mmap can overrun buffer

[SourceForge.net]

Bugs item #1733986, was opened at 2007-06-09 03:53
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=1733986&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap.mmap can overrun buffer

Initial Comment:
When opening a named mapping (windows only) that already exists, the size is 
ignored but the constructor assumes the passed-in size is the buffer size.  If 
you specify a size larger than the original, the reopened mapping can write 
past the end of the valid buffer, resulting in a crash.


--

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

[ python-Bugs-1734111 ] struct.Struct.size is not documented

[SourceForge.net]

Bugs item #1734111, was opened at 2007-06-09 23:53
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=1734111&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yang Yang (wdscxsj)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.Struct.size is not documented

Initial Comment:
In Python 2.5 documentation, a description for struct.Struct.size is missing, 
although this member has been quoted in descriptions for struct.Struct.pack, 
struct.Struct.unpack, and struct.Struct.unpack_from.

--

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

[issue1001] New issue test for email

[admin]

Changes by admin:


--
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1734164 ] sqlite3 causes memory read error

[SourceForge.net]

Bugs item #1734164, was opened at 2007-06-10 03:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1734164&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: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlite3 causes memory read error

Initial Comment:
Attached script causes memory read error at sqlite3.pyd.
Tested on Python 2.5.1/Windows XP.

--

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