Joseph J VLcek wrote:
> Keith Mitchell wrote:
>> Hi Joe,
>>
>> Joseph J VLcek wrote:
>>> Keith Mitchell wrote:
>>>> Hi,
>>>>
>>>> The Text Installer, being built on the curses module of Python, is
>>>> expected to work on most terminal types 'by default,' with the
>>>> expectation that the underlying Python curses module, Ncurses
>>>> library, and terminfo data will correctly handle the calls used.
>>>> With that in mind, there are three terminal types that will get
>>>> explicit testing:
>>>>
>>>> sun-color
>>>> vt100
>>>> xterm*
>>>>
>>>> *xterm getting tested is a side effect of developing the Text
>>>> Installer from a gnome desktop, and frequently running it from a
>>>> gnome-terminal.
>>>>
>>>> My question is, are there any other major terminals that deserve
>>>> explicit testing?
>>>>
>>>> - Keith
>>>
>>> Is there a documented list of terminals which the "Python curses
>>> module" is supposed to support?
>>>
>>> I briefly poked around the docs.python.org and did not find a list.
>>>
>>> If a documented list of terminals supported by "Python curses
>>> module" can be found it could help us decide what set we should test
>>> on.
>>
>> Since build 124, the Python curses module delivered in SUNWPython
>> (and SUNWPython26) is linked against the Ncurses library. The Ncurses
>> library in turn delivers a number of terminfo entries to
>> /usr/gnu/share/terminfo.
>>
>> For a full list:
>> pkg contents SUNWncurses | grep terminfo
>>
>> However, the existence of a terminfo entry doesn't guarantee that the
>> Text Installer will run properly on the terminal. If the terminfo
>> entry is incorrect, outdated, or does not support functionality used
>> by the Text Installer, the results are indeterminate. In the case of
>> incorrect or outdated entries, bugs should be filed against
>> SUNWncurses. For example, sun-color was incorrect as of build 124 -
>> though it should be correct in 125.
>>
>> The biggest example of the non-supported functionality case is color:
>> on terminals that don't support color, attempts to call curses
>> functions that manipulate color will error out. In this specific
>> case, it's easy enough to check if the terminal supports color and
>> branch the code based on that. Most other situations either have
>> explicit curses calls for checking if the functionality exists, or
>> intelligent fallbacks implemented automatically.
>>
>> - Keith
>>>
>>> Joe
>
> Keith
>
> Thanks for the explanation!
>
> Is there a "Python curses module" automated test? Maybe something like
> what netperf provides for networking... ?
The SUNWPython package comes with a /usr/lib/python2.4/test/ directory,
which contains regrtest.py and a set of test suites, including one for
the curses module. Normally, one runs the tests by executing:
python2.4 /usr/lib/python2.4/test/regrtest.py
However, the curses module is not tested by default (I don't know the
justification for that either). To include it in the test run, execute:
python2.4 /usr/lib/python2.4/test/regrtest.py -u curses
This runs the full test gamut, plus the curses module tests. From
looking at the curses module test (/usr/lib/python2.4/test/test_curses.py):
> #
> # Test script for the curses module
> #
> # This script doesn't actually display anything very coherent. but it
> # does call every method and function.
> #
> # Functions not tested: {def,reset}_{shell,prog}_mode, getch(), getstr(),
> # init_color()
> # Only called, not tested: getmouse(), ungetmouse()
The tests for the most part appear to simply call the function and see
if any errors occur (or in some cases, attempt to call them with invalid
parameters and verify that an error occurs).
Assuming that the curses module tests provide sufficient coverage, I
imagine it would need to be run in the context of each terminal
(meaning, run from an xterm to test the xterm entry, run from the
console to test sun-color, etc.) - but that's an assumption on my part.
- Keith
>
> Joe
