[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-06 23:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix
Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input.
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range. This means that getpass can
not be used cross-platform for complex passwords.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 10:46
Message:
Logged In: YES
user_id=1188172
What makes you think that? I tried it on Windows XP, in a
cmd.exe session.
I could enter, for example, an ü (umlauted u), which in the
resulting string came out encoded as \x81, as is correct in
the encoding used by the console window, namely cp850. I
could then convert this to latin1 by using
s.decode(sys.stdin.encoding).encode("latin-1").
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-07 09:36
Message generated for change (Comment added) made by esrever_otua
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix
Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input.
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range. This means that getpass can
not be used cross-platform for complex passwords.
--
>Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 21:18
Message:
Logged In: YES
user_id=567623
I think that, because I've read the source, and
getpass.getpass() uses msvcrt.getch() on Windows, which
doesn't support anything at all above ASCII 255.
Also because I have a bug report pending against one of the
projects that I maintain from a user that is experiencing a
problem because of exactly this issue.
See:
https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935
Also, I call shenanigans on your claim of successfully
inputting an umlaut-u into getpass.getpass(); this character
can *theoretically* be input, as it's below ASCII 255, but
in practice I can neither input it directly, nor COPY+PASTE
it from the clipboard on my WinXP SP2 with Python 2.4.1
installed.
Finally, regardless of whether "ü" works or not, other
characters that live solely in unicode, such as "¿" most
certainly do not (and never will) work (not even theoretically).
Regards,
D
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 20:46
Message:
Logged In: YES
user_id=1188172
What makes you think that? I tried it on Windows XP, in a
cmd.exe session.
I could enter, for example, an ü (umlauted u), which in the
resulting string came out encoded as \x81, as is correct in
the encoding used by the console window, namely cp850. I
could then convert this to latin1 by using
s.decode(sys.stdin.encoding).encode("latin-1").
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-06 23:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix
Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input.
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range. This means that getpass can
not be used cross-platform for complex passwords.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 12:01
Message:
Logged In: YES
user_id=1188172
First of all, don't accuse me of lying. If I wanted to lie
professionally, I would have become politician, not programmer.
I'm German, and using a German keyboard layout which does
have the ü, so it can be perfectly input.
Your problem is that you cannot input characters which don't
directly create keycodes on the keyboard, but must be copied
to the console in some way.
In python-dev, you said that msvcrt.getch() would have to
call _getch() a second time in the case that it returns 0x00
or 0xe0 the first time and/or return a Unicode string.
First, the documentation for _getch() says that this is a
special case for arrow and function keys (such as F1 or
). These keys don't have a representation in any
character set, as they are control keys, so how would you
represent them as Unicode?
Second: In my console, pressing F7 yields the return values
"\x00" and "A".
When the 0x00/0xe0 read the first time is secretly
swallowed, the user of msvcrt.getch() can't know whether the
user pressed "A" or F7.
That said, the behaviour of getch() is documented and correct.
But how does that all help you with your original problem,
which is that _getch() doesn't help you with Alt+
sequences or console window Copy-Paste? In my understanding
_getch() only works with characters directly input to the
console. Sorry, but then this is not a Python problem but a
Windows one.
--
Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 11:18
Message:
Logged In: YES
user_id=567623
I think that, because I've read the source, and
getpass.getpass() uses msvcrt.getch() on Windows, which
doesn't support anything at all above ASCII 255.
Also because I have a bug report pending against one of the
projects that I maintain from a user that is experiencing a
problem because of exactly this issue.
See:
https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935
Also, I call shenanigans on your claim of successfully
inputting an umlaut-u into getpass.getpass(); this character
can *theoretically* be input, as it's below ASCII 255, but
in practice I can neither input it directly, nor COPY+PASTE
it from the clipboard on my WinXP SP2 with Python 2.4.1
installed.
Finally, regardless of whether "ü" works or not, other
characters that live solely in unicode, such as "¿" most
certainly do not (and never will) work (not even theoretically).
Regards,
D
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 10:46
Message:
Logged In: YES
user_id=1188172
What makes you think that? I tried it on Windows XP, in a
cmd.exe session.
I could enter, for example, an ü (umlauted u), which in the
resulting string came out encoded as \x81, as is correct in
the encoding used by the console window, namely cp850. I
could then convert this to latin1 by using
s.decode(sys.stdin.encoding).encode("latin-1").
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-07 09:36 Message generated for change (Comment added) made by esrever_otua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open Resolution: None Priority: 5 Submitted By: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. -- >Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 22:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ü below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '¿' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 22:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ü, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+ sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python problem but a Windows one. -- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 21:18 Message: Logged In: YES user_id=567623 I think that, because I've read the source, and getpass.getpass() uses msvcrt.getch() on Windows, which doesn't support anything at all above ASCII 255. Also because I have a bug report pending against one of the projects that I maintain from a user that is experiencing a problem because of exactly this issue. See: https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935 Also, I call shenanigans on your claim of successfully inputting an umlaut-u into getpass.getpass(); this character can *theoretically* be input, as it's below ASCII 255, but in practice I can neither input it directly, nor COPY+PASTE it from t
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-06 23:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open Resolution: None Priority: 5 Submitted By: Darryl Dixon (esrever_otua) Assigned to: Nobody/Anonymous (nobody) Summary: getpass.getpass() performs differently on Windows vs *nix Initial Comment: getpass.getpass() on *nix platforms allows users to input unicode characters and other NLS input. getpass.getpass() on Windows only allows ASCII input in the 0-127 codepage range. This means that getpass can not be used cross-platform for complex passwords. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 12:29 Message: Logged In: YES user_id=1188172 Okay. This isn't menat to attempt a flamewar, but rather find out what can be done to help you (and, thank you very much for making it simple extra for me, I would have preferred the simple version even if I was a native speaker). You're right that this bug report is about getpass's portability, I had a bit lost track of this. Since you posted the link to your tracker in your previous comment, I somehow linked this to here. I have only two questions left. 1) Do you know another function in the MS API that allows reading a character from the console without displaying it? 2) How do you input your characters under the sun on Unix? Can you do this on a text console, too? -- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-07 12:15 Message: Logged In: YES user_id=567623 Right. I've had enough of this nonsense, listen carefully: as English isn't your first language I'll make this as simple as possible: 1) I didn't come here to start a flame war, but rather to point out a genuine deficiency in the Windows getpass, compared to the *nix version. 2) You didn't lie, and *I didn't accuse you of that*, but rather pointed out that all was not correct or complete in your assertion. *I* was right, as you carefully neglected to mention that you're using a native keyboard, with an NLS system that puts ü below ASCII 127 in your local codepage 3) getpass.getpass(), when called on *nix, allows me to input '¿' and every other character under the sun. When called on Windows, *it does not*. This Means Complex Passwords With getpass() Aren't Portable. End Of Story. It Is Undocumented. This Is A Bug. 4) Yes the problem isn't that getch() isn't doing what it should, it is that getch() is the *wrong function to use* in order to gain parity with the *nix version. 5) Finally, you seem hell-bent on ignoring what I've written. I was wrong about getch() behaviour on python-dev, but That Isn't The Problem, which is why *I* didn't mention it in this initial bug-report. My assertion below that getch() won't get anything above ASCII 255 is *completely accurate*. It is the Wrong Function To Use. This Is A Bug In Getpass. 6) Finally, Finally, please read this and understand: As per the initial bug-report, the problem is that getpass on Windows is limited in ways that getpass on *nix isn't. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-07 12:01 Message: Logged In: YES user_id=1188172 First of all, don't accuse me of lying. If I wanted to lie professionally, I would have become politician, not programmer. I'm German, and using a German keyboard layout which does have the ü, so it can be perfectly input. Your problem is that you cannot input characters which don't directly create keycodes on the keyboard, but must be copied to the console in some way. In python-dev, you said that msvcrt.getch() would have to call _getch() a second time in the case that it returns 0x00 or 0xe0 the first time and/or return a Unicode string. First, the documentation for _getch() says that this is a special case for arrow and function keys (such as F1 or ). These keys don't have a representation in any character set, as they are control keys, so how would you represent them as Unicode? Second: In my console, pressing F7 yields the return values "\x00" and "A". When the 0x00/0xe0 read the first time is secretly swallowed, the user of msvcrt.getch() can't know whether the user pressed "A" or F7. That said, the behaviour of getch() is documented and correct. But how does that all help you with your original problem, which is that _getch() doesn't help you with Alt+ sequences or console window Copy-Paste? In my understanding _getch() only works with characters directly input to the console. Sorry, but then this is not a Python
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-07 09:36
Message generated for change (Comment added) made by esrever_otua
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&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: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix
Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input.
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range. This means that getpass can
not be used cross-platform for complex passwords.
--
>Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 22:42
Message:
Logged In: YES
user_id=567623
I am not an expert C coder (no surprise) however this simple
code I wrote will accept a line of input (including the \r\n
on the end) without echoing it back to the user:
#include
#define LINE_BUF 65536
char *getstr(){
/*
* OK, basically, we get a handle to STDIN, take a copy
of the
* flags currently in force, set our own to prevent
screen echo,
* do a read of the console that returns on '\r\n'
(included in
* returned string), restore the original flags on
STDIN, and
* finally returns the input string.
*
* This is basically a re-implementation of getch(), but
instead
* of a single char, you get a whole string (with no
screen echo).
*
* For docs on functions called, see:
*
http://msdn.microsoft.com/library/en-us/dllproc/base/console_functions.asp
*/
HANDLE hstdin;
DWORD read_chars, mode;
char in_chars[LINE_BUF];
hstdin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hstdin,
&mode);
SetConsoleMode(hstdin,
ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT);
ReadConsole(hstdin,
in_chars,
LINE_BUF,
&read_chars,
NULL);
SetConsoleMode(hstdin,
mode);
return in_chars;
}
This code, when SWIG-ed to use with Python 2.4.1 works
perfectly. The key is setting the flags on the console
handle to remove the ENABLE_ECHO_INPUT flag. Also, if
ENABLE_LINE_INPUT is removed, theoretically the
ReadConsole() function should return after each typed character.
On *nix you can use unicode_start and loadkeys to input
unicode directly, including ALT+ style input.
Regards,
D
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 22:29
Message:
Logged In: YES
user_id=1188172
Okay. This isn't menat to attempt a flamewar, but rather
find out what can be done to help you (and, thank you very
much for making it simple extra for me, I would have
preferred the simple version even if I was a native speaker).
You're right that this bug report is about getpass's
portability, I had a bit lost track of this. Since you
posted the link to your tracker in your previous comment, I
somehow linked this to here.
I have only two questions left.
1) Do you know another function in the MS API that allows
reading a character from the console without displaying it?
2) How do you input your characters under the sun on Unix?
Can you do this on a text console, too?
--
Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 22:15
Message:
Logged In: YES
user_id=567623
Right. I've had enough of this nonsense, listen carefully:
as English isn't your first language I'll make this as
simple as possible:
1) I didn't come here to start a flame war, but rather to
point out a genuine deficiency in the Windows getpass,
compared to the *nix version.
2) You didn't lie, and *I didn't accuse you of that*, but
rather pointed out that all was not correct or complete in
your assertion. *I* was right, as you carefully neglected
to mention that you're using a native keyboard, with an NLS
system that puts ü below ASCII 127 in your local codepage
3) getpass.getpass(), when called on *nix, allows me to
input '¿' and every other character under the sun. When
called on Windows, *it does not*. This Means Complex
Passwords With getpass() Aren't Portable. End Of Story. It
Is Undocumented. This Is A Bug.
4) Yes the problem isn't that getch() isn't doing what it
should, it is that getch() is the *wrong function to use* in
order to gain parity with the *nix version.
5) Finally, you seem hell-bent on ignoring what I've
written. I was wrong about getch() behaviour on python-dev,
but That Isn't The Problem, which is why *I* didn't mention
it in this initia
[ python-Bugs-1234123 ] datetime.strftime %s
Bugs item #1234123, was opened at 2005-07-07 13:39
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=1234123&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Kleiweg (peterkleiweg)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime.strftime %s
Initial Comment:
I don't know if this is a bug in datetime or in pytz,
so I submitted this as a bug with pytz as well:
https://sourceforge.net/tracker/index.php?func=detail&aid=1233776&group_id=79122&atid=90
The first example does not give the result I expect.
The second does.
Python 2.3.4 (#1, Aug 6 2004, 18:12:39)
[GCC 2.95.3 20010315 (SuSE)] on linux2
>>> from datetime import datetime
>>> from pytz import timezone
>>> utc = timezone('UTC')
>>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc)
>>> print utc_dt
1970-01-01 00:00:00+00:00
>>> print utc_dt.strftime('%c * %Z * %s')
Thu Jan 1 00:00:00 1970 * UTC * -3600
Python 2.3.4 (#1, Aug 6 2004, 18:12:39)
[GCC 2.95.3 20010315 (SuSE)] on linux2
>>> import os
>>> os.environ['TZ'] = 'UTC'
>>> from datetime import datetime
>>> from pytz import timezone
>>> utc = timezone('UTC')
>>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc)
>>> print utc_dt
1970-01-01 00:00:00+00:00
>>> print utc_dt.strftime('%c * %Z * %s')
Thu Jan 1 00:00:00 1970 * UTC * 0
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234123&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234328 ] 'insufficient disk space' message wrong (msi on win xp pro)
Bugs item #1234328, was opened at 2005-07-07 20:01 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=1234328&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Nobody/Anonymous (nobody) Summary: 'insufficient disk space' message wrong (msi on win xp pro) Initial Comment: I'm trying to do a non-admin install of python 2.4.1 using the msi on win xp pro. Our environment is pretty customized; in an ordinary explorer window I see drives I, J but no C. "My Documents" refers to i:\ which is an alias for \\\username. I'm installing to i:\\python241 for my user only. The server has enough diskspace and my diskspace is not limited. When I try to install, bug #1232947 occurs; but when I try to do the same install with a usb-stick attached (which appears as volume "e:"), the installer complains that E has insufficient disk space. In fact, this was true: but I was not installing on E but on I. The disk usage button by the way shows enough diskspace on I: and does not list E: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77
Bugs item #1234473, was opened at 2005-07-07 16:37 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=1234473&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: Open Resolution: None Priority: 5 Submitted By: Tekhne (tekhne0) Assigned to: Nobody/Anonymous (nobody) Summary: configure: error: cannot compute sizeof (int), 77 Initial Comment: After running: shell# configure --prefix=/opt/python Various warnings were produced, and one fatal error preventing the build from progressing: checking size of int... configure: error: cannot compute sizeof (int), 77 The attachment contains the config.log file from the configure command. Build was done with Python 2.4.1 on Solaris 10 (sparc) with gcc 3.3.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234473 ] configure: error: cannot compute sizeof (int), 77
Bugs item #1234473, was opened at 2005-07-07 16:37 Message generated for change (Comment added) made by tekhne0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&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: Open Resolution: None Priority: 5 Submitted By: Tekhne (tekhne0) Assigned to: Nobody/Anonymous (nobody) Summary: configure: error: cannot compute sizeof (int), 77 Initial Comment: After running: shell# configure --prefix=/opt/python Various warnings were produced, and one fatal error preventing the build from progressing: checking size of int... configure: error: cannot compute sizeof (int), 77 The attachment contains the config.log file from the configure command. Build was done with Python 2.4.1 on Solaris 10 (sparc) with gcc 3.3.2. -- >Comment By: Tekhne (tekhne0) Date: 2005-07-07 16:44 Message: Logged In: YES user_id=1309274 attachment didn't go through...trying again. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234473&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 03:05
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&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: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load
Initial Comment:
trying to do a
hotshot.stats.load("myprofiling_file.prof")
fails with assertionerror
assert not self._stack
python 2.3.2 on WinXP
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 19:26
Message:
Logged In: YES
user_id=12800
See 900092-patch.txt for a candidate patch against Python
2.4.1. Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).
This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 18:54
Message:
Logged In: YES
user_id=86307
Well, the superficial fix doesn't work (sorry for posting
too soon). It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit.
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs. Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").
By the way, I'm testing with 2.4b1.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 18:32
Message:
Logged In: YES
user_id=86307
I ran into this today, so I decided to look into it. It
looks to me like the problem only happens if you profile
with lineevents enabled. In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events. This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).
It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns. This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 10:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 18:00
Message:
Logged In: YES
user_id=469548
Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 17:58
Message:
Logged In: YES
user_id=469548
While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:
Python 2.3.4 (#2, Jul 5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
return StatsLoader(filename).load()
File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
assert not self._stack
AssertionError
>>>
I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 03:05
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load
Initial Comment:
trying to do a
hotshot.stats.load("myprofiling_file.prof")
fails with assertionerror
assert not self._stack
python 2.3.2 on WinXP
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 19:26
Message:
Logged In: YES
user_id=12800
See 900092-patch.txt for a candidate patch against Python
2.4.1. Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).
This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 18:54
Message:
Logged In: YES
user_id=86307
Well, the superficial fix doesn't work (sorry for posting
too soon). It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit.
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs. Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").
By the way, I'm testing with 2.4b1.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 18:32
Message:
Logged In: YES
user_id=86307
I ran into this today, so I decided to look into it. It
looks to me like the problem only happens if you profile
with lineevents enabled. In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events. This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).
It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns. This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 10:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 18:00
Message:
Logged In: YES
user_id=469548
Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 17:58
Message:
Logged In: YES
user_id=469548
While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:
Python 2.3.4 (#2, Jul 5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
return StatsLoader(filename).load()
File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
assert not self._stack
AssertionError
>>>
I'm not sure who's baby hotshot really is, so I'm leaving
this unassigned.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
