[ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set
Bugs item #1119331, was opened at 2005-02-09 14:51
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacob Lilly (jrlilly)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses.initscr - initscr exit w/o env(TERM) set
Initial Comment:
the initscr in ncurses will cause an immeadiation exit
if the env doesn't have the TERM variable set. Could
the curses.initscr be changed so it tests if TERM is
set and raises an exception? It would be helpful to be
able to try and except this instead of just having
ncurses exit for you.
--
>Comment By: Michael Hudson (mwh)
Date: 2005-02-10 11:22
Message:
Logged In: YES
user_id=6656
The motivation for calling setupterm() ourselves was that I noticed
TERM=garbage python -c 'import curses; curses.initscr()'
hit the irritating error path too. I also hadn't realised there was a
version of initscr in curses/__init__.py, which makes things easier... how
about the attached?
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-10 00:06
Message:
Logged In: YES
user_id=774886
if you pass setupterm 0 for the term name it just tries to
get the env variable, so the env test should cover it pretty
well. It might make more sense to check the env first and
then pass "unkown", setuperm("unknown", -1). This would
seem to match the path that curses initscr follows. This
would also raise _curses and curses shared exception.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 23:19
Message:
Logged In: YES
user_id=6656
Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I
guess...
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 19:51
Message:
Logged In: YES
user_id=774886
that is any return of 0 from newterm
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 19:49
Message:
Logged In: YES
user_id=774886
sorry, I should have done that in the beginning; I have it
raising a RuntimeError, I think thats what it is. This
doesn't really solve the problem in whole, since ncurses
initscr has lots of ways it could decide to decide to exit
(any return value from newterm causes it to exit), but it
does solve a more common one. Anything else would require
modifying ncruses to be responsible.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 18:45
Message:
Logged In: YES
user_id=6656
How amazingly terrible (on ncurses part). Do you want to/are you able
to work on a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1119331 ] curses.initscr - initscr exit w/o env(TERM) set
Bugs item #1119331, was opened at 2005-02-09 08:51
Message generated for change (Comment added) made by jrlilly
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacob Lilly (jrlilly)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses.initscr - initscr exit w/o env(TERM) set
Initial Comment:
the initscr in ncurses will cause an immeadiation exit
if the env doesn't have the TERM variable set. Could
the curses.initscr be changed so it tests if TERM is
set and raises an exception? It would be helpful to be
able to try and except this instead of just having
ncurses exit for you.
--
>Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-10 07:41
Message:
Logged In: YES
user_id=774886
The only thing that worries me about that is it takes a
different path than ncurses does (or at least 5.4 does). If
the env variable isn't set, initscr in ncurses assumes the
term type is "unknown" (if no env) and passes "unknown"
along, whereas setupterm assumes that if you pass it NULL
for the term and the env isn't set, then it simply returns
0. I doubt anyone will have a valid term setup for unknown,
but who knows. Beyound that works for me. BTW, the gnu
ncurses guys say this is the the behavior in the standard.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-10 05:22
Message:
Logged In: YES
user_id=6656
The motivation for calling setupterm() ourselves was that I noticed
TERM=garbage python -c 'import curses; curses.initscr()'
hit the irritating error path too. I also hadn't realised there was a
version of initscr in curses/__init__.py, which makes things easier... how
about the attached?
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 18:06
Message:
Logged In: YES
user_id=774886
if you pass setupterm 0 for the term name it just tries to
get the env variable, so the env test should cover it pretty
well. It might make more sense to check the env first and
then pass "unkown", setuperm("unknown", -1). This would
seem to match the path that curses initscr follows. This
would also raise _curses and curses shared exception.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 17:19
Message:
Logged In: YES
user_id=6656
Yeah, I noticed that. We could at least call setupterm(0, NULL) first, I
guess...
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 13:51
Message:
Logged In: YES
user_id=774886
that is any return of 0 from newterm
--
Comment By: Jacob Lilly (jrlilly)
Date: 2005-02-09 13:49
Message:
Logged In: YES
user_id=774886
sorry, I should have done that in the beginning; I have it
raising a RuntimeError, I think thats what it is. This
doesn't really solve the problem in whole, since ncurses
initscr has lots of ways it could decide to decide to exit
(any return value from newterm causes it to exit), but it
does solve a more common one. Anything else would require
modifying ncruses to be responsible.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-09 12:45
Message:
Logged In: YES
user_id=6656
How amazingly terrible (on ncurses part). Do you want to/are you able
to work on a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119331&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1120452 ] Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED
Bugs item #1120452, was opened at 2005-02-11 01:04 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=1120452&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.0 crashes with a segfault, EXAMPLE ATTACHED Initial Comment: Running the attached example crashes python 2.4.0 on linux (segfault) and Windows. Python is compiled on Debian Linux 3.0r3 (Woody). On Windows XP, I used the MSI installer downloaded from python.org This may be a problem with the regular expression module, but I'm not sure. Please assign a new category if it appears as a regexp bug. This bug causes permanent crashes in my new WEB applications. Old apps not using regexp and PyMeld seem to run correctly. Thanks for 2.4.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120452&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included)
Feature Requests item #1087418, was opened at 2004-12-18 00:22 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: long int bitwise ops speedup (patch included) Initial Comment: The 'inner loop' for applying bitwise ops to longs is quite inefficient. The improvement in the attached diff is - 'a' is never shorter than 'b' (result: only test 1 loop index condition instead of 3) - each operation ( & | ^ ) has its own loop, instead of switch inside loop - I found that, when this is done, a lot of things can be simplified, resulting in further speedup, and the resulting code is not very much longer than before (my libpython2.4.dll .text got 140 bytes longer). Operations on longs of a few thousand bits appear to be 2 ... 2.5 times faster with this patch. I'm not 100% sure the code is right, but it passes test_long.py, anyway. -- >Comment By: Gregory Smith (gregsmith) Date: 2005-02-10 22:45 Message: Logged In: YES user_id=292741 I started by just factoring out the inner switch loop. But then it becomes evident that when op = '^', you always have maska == maskb, so there's no point in doing the ^mask at all. And when op == '|', then maska==maskb==0. So likewise. And if you put a check in so that len(a) >= len(b), then the calculation of len_z can be simplified. It also becomes easy to break the end off the loops, so that, say, or'ing a small number with a really long becomes mostly a copy. etc. It's was just a series of small simple changes following from the refactoring of the loop/switch. I see a repeatable 1.5 x speedup at 300 bits, which I think is significant (I wasn't using negative #s, which of course have their own extra overhead). The difference should be even higher on CPUs that don't have several 100 mW of branch-prediction circuitry. One use case is that you can simulate an array of hundreds or thousands of simple 1-bit processors in pure python using long operations, and get very good performance, even better with this fix. This app involves all logical ops, with the occasional shift. IMHO, I don't think the changed code is more complex; it's a little longer, but it's more explicit in what is really being done, and it doesn't roll together 3 cases, which don't really have that much in common, for the sake of brevity. It wasn't obvious to me about the masks being redundant until after I did the factoring, and this is my point - rolling it together hides that. The original author may not have noticed the redundancy. I see a lot of effort being expended on very complex multiply operations, why should the logical ops be left behind for the sake of a few lines? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-07 01:54 Message: Logged In: YES user_id=80475 Patch Review On Windows using MSC 6.0, I could only reproduce about a small speedup at around 300 bits. While the patch is short, it adds quite a bit of complexity to the routine. Its correctness is not self-evident or certain. Even if correct, it is likely to encumber future maintenance. Unless you have important use cases and feel strongly about it, I think this one should probably not go in. An alternative to submit a patch that limits its scope to factoring out the innermost switch/case. I tried that and found that the speedup is microscopic. I suspect that that one unpredictable branch is not much of a bottleneck. More time is likely spent on creating z. -- Comment By: Gregory Smith (gregsmith) Date: 2005-01-03 14:54 Message: Logged In: YES user_id=292741 I originally timed this on a cygwin system, I've since found that cygwin timings tend to be strange and possibly misleading. On a RH8 system, I'm seeing speedup of x3.5 with longs of ~1500 bits and larger, and x1.5 speedup with only about 300 bits. Times were measured with timeit.Timer( 'a|b', 'a=...; b=...') Increase in .text size is likewise about 120 bytes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
