pythondialog-users — Discussions for users and developers

Re: [Pythondialog-users] UnableToRetrieveBackendVersion (python2-pythondialog, Debian squeeze)

[Florent R. <f.r...@fr...>]

Hello,

Jakub Warmuz <jak...@gm...> wrote:

> Debian squeeze (afftected, deb version: 1.1-20100428-1):
>
>   root@le-squeeze:~# dialog --print-version --stderr >/dev/null
>   root@le-squeeze:~# dialog --print-version --stderr >/dev/null | wc
>         0       0       0
>       
> and for wheezy (unaffected, deb version: 1.1-20120215-2):
>
>   root@le-wheezy-64:~# dialog --print-version --stderr >/dev/null
>   Version: 1.1-20120215
>
> I'm afraid --stderr in squeeze is broken as well :(

Okay. I've pushed a workaround that works on squeeze with Python 3.1,
along with a few other fixes for bugs uncovered by the "new" test
environment. They are in the master branch of the Git repo
(http://pythondialog.sourceforge.net/), i.e. for Python 3. I will
backport them to Python 2.

-- 
Florent

Re: [Pythondialog-users] UnableToRetrieveBackendVersion (python2-pythondialog, Debian squeeze)

[Jakub W. <jak...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Apr 02, 2015 at 04:03:20PM +0200, Florent Rougon wrote:
> Yup, this must be the root of the problem. Normally, dialog prints the
> version on stderr, but it seems that old or buggy versions print it on
> stdout instead. The cleanest workaround would be to manage to tell
> dialog to print the version on stderr. What is the output of the
> following command on the affected system?
> 
>   dialog --print-version --stderr >/dev/null
>

Debian squeeze (afftected, deb version: 1.1-20100428-1):

  root@le-squeeze:~# dialog --print-version --stderr >/dev/null
  root@le-squeeze:~# dialog --print-version --stderr >/dev/null | wc
        0       0       0
      
and for wheezy (unaffected, deb version: 1.1-20120215-2):

  root@le-wheezy-64:~# dialog --print-version --stderr >/dev/null
  Version: 1.1-20120215

I'm afraid --stderr in squeeze is broken as well :(

- -- 
Kuba
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJVHVYVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMzBGQ0QzNkIzOTBBOTMwODc1OTAzREYy
QTdCQUQzQTQ4OUI1MkVBAAoJECp7rTpIm1Lq8+YP/Aqo7+MAgAAF13fhbTGvz/Mc
LCsW0k2VrBzkwHrCZNXnHxDCl8eOkUTG+S/3+mnBBmtygIcQqb4rb3Wc0z8/Utu0
rOXUwnTvoa/jn33DYrOmxmZo+DgC8JFfLdjyEdgTelRrYXSzOkWKrfFyMlKdENUc
aBHdP6F7pKX+eHowbrM1EYvthPufYUHM/00scS1AxxZPA5HvTg6FvVwk82o25MGp
yNIoiP6uRT5XvelCBOQ+raHWhYTPRq3Ljb6dNohAZsmzI88r2yIrgPt0jXZ6DbpL
f1T3RlEtaONTfcChdP4H9ySINSAY++mgYXayC1mZCH/fJ3ZycMi1FwFVf6i+YK+l
UzhkDgZkifZW8pQf4RZ6FCD0FFQBCeBOLHd+nqYGI3Xry3VjjdJ2La6hNQJtt4Bx
9Zqq74XKUVPIiSXf/UO6X3L4GghEXK1Z7kwtGo+YLEYI0xEJNbfHlCVOw4Pr+92h
IbDSZZG5THZC1+eEOvocCHCJPxmuSKYaKeUtO6ho6gd4YiDIGtxSCzIJ/qN7DAUd
sqQHZMLDc3Cv++GdzIGWGIvgtVegv0DmjDW0Dk7vVXT6sx3xYRQkkryiAMzAI5Fq
ae7jRuzFYoKt0Qe5T/tiRf76T0Rs+NBb9zs0fG1nBxbIDm5VnF1BEkCWS5SZu26R
l/AskZm01roAX1uPWmoA
=DVYB
-----END PGP SIGNATURE-----

Re: [Pythondialog-users] UnableToRetrieveBackendVersion (python2-pythondialog, Debian squeeze)

[Florent R. <f.r...@fr...>]

Hello,

Thanks for your detailed report.

Jakub Warmuz <jak...@gm...> wrote:

> While working on the Let's Encrypt [1] client we have hit the
> following python2-pythondialog bug [2] on Debian squeeze (tested on
> digitalocean droplet):

[...]

> Please note that the version string is printed on the terminal. I have
> checked (using pdb) that "output" on line 2028 is set to empty string:
> ''. More debug output:
>
>   (venv)root@le-squeeze:/tmp# dialog --print-version 2>/dev/null
>   Version: 1.1-20100428

Yup, this must be the root of the problem. Normally, dialog prints the
version on stderr, but it seems that old or buggy versions print it on
stdout instead. The cleanest workaround would be to manage to tell
dialog to print the version on stderr. What is the output of the
following command on the affected system?

  dialog --print-version --stderr >/dev/null

> We don't have this problem on neither Debian wheezy nor Ubuntu 14.04
> nor Ubuntu 14.10.

OK.

> BTW I wanted to use sourceforge bug tracker [3] to report this
> problem, but it says: "To create a new ticket, you must be authorized
> by the project admin.".

Ah, thank you for reporting this! Silly permission problem for the
tracker. I thought it was working since there were a few bug reports in
it when I took over in 2013. Who knows how long it has been broken?..

Regards

-- 
Florent

[Pythondialog-users] UnableToRetrieveBackendVersion (python2-pythondialog, Debian squeeze)

[Jakub W. <jak...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

While working on the Let's Encrypt [1] client we have hit the
following python2-pythondialog bug [2] on Debian squeeze (tested on
digitalocean droplet):

  (venv)root@le-squeeze:/tmp# pip install python2-pythondialog
  Downloading/unpacking python2-pythondialog
  Downloading python2-pythondialog-3.0.1.tar.bz2 (76Kb): 76Kb downloaded
  Running setup.py egg_info for package python2-pythondialog
  No .git directory, using the 'ChangeLog' file as is.
  Installing collected packages: python2-pythondialog
  Running setup.py install for python2-pythondialog
  No .git directory, using the 'ChangeLog' file as is.
  Successfully installed python2-pythondialog
  Cleaning up...
  (venv)root@le-squeeze:/tmp# python -c 'import dialog; dialog.Dialog()'
  Version: 1.1-20100428
  Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/venv/lib/python2.6/site-packages/dialog.py", line 1366, in __init__
  self.backend_version())
  File "/tmp/venv/lib/python2.6/site-packages/dialog.py", line 2028, in backend_version
  "{1!r}".format(self._dialog_prg, output))
  dialog.UnableToRetrieveBackendVersion

Please note that the version string is printed on the terminal. I have
checked (using pdb) that "output" on line 2028 is set to empty string:
''. More debug output:

  (venv)root@le-squeeze:/tmp# dialog --print-version 2>/dev/null
  Version: 1.1-20100428

We don't have this problem on neither Debian wheezy nor Ubuntu 14.04
nor Ubuntu 14.10.

BTW I wanted to use sourceforge bug tracker [3] to report this
problem, but it says: "To create a new ticket, you must be authorized
by the project admin.".


[1] https://letsencrypt.org
[2] https://github.com/letsencrypt/lets-encrypt-preview/issues/280
[3] http://sourceforge.net/p/pythondialog/bugs/

- -- 
Your's virtually,
Jakub Warmuz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJVHR90XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMzBGQ0QzNkIzOTBBOTMwODc1OTAzREYy
QTdCQUQzQTQ4OUI1MkVBAAoJECp7rTpIm1LqSBIP/34LRqVn0Ij9Ieml07zYvpB/
ocVVCRMF/j7ghH/u1zDARNXstmPH3zN/teQW+GJpml6LTe248r519/6AJq/PcR8v
lIdODhrISp78ULuaNU12mvVkFABB5yiVUu9d8WH5wKL/30jn5vUBnp+ej59Ywfx9
7OTk8EcFhRLNBNCJHyxEMTLYuQqzkXxhHZE03o8B7JsK1NzCHwPB9XoDaOE0Nj3q
Zs3yVfHMiPIbUJDmXREgFdg7tqf2LC6DJYC9IhvIWFllJ0zfMvBNqarG9b1NGQha
q9H8Bsp+QFKRPOZhxmPrSuUFMvGNoKAMJh98kSLO4itq6TVEQ/KIm2t+6RAdKvwb
9jPZpSgJkqlLPbifQ4XNPp/jeDBzbPYsTB7Bzw6QZTA2mmRHjQKm+YDhAHuGvqix
X26qOXd9hua7gHzihQukldHBLzW7L13rLWZJsig6lv/oBlKKfQfb7OseUboqrZt1
SfFT8z00nS6bL6Jz2KU80efcF8Roq3Rv0DqQKjjzeTJA9CMl0gXB2zryFDv258le
qTZ+kFkz7W9cn8z3GSlIipXVNwj6nxEy3Biz3Hg9Rrb+c4Ma7fabvhssDeT/C5jd
mN0JhaB3VYcrYu2tqHamf2oTnfru9fYhlaAx1gWhYtoxj9b498CMkuKP/wvJZGn2
mqtB5o/h2YOQxX2YUMOn
=EHS8
-----END PGP SIGNATURE-----

Re: [Pythondialog-users] Function keys

[Florent R. <f.r...@fr...>]

Hello,

Fons van der Beek - 84-IT BV <fon...@84...> wrote:

> I want to add Function key support to an application and want to use 
> pythondialog.
> Can someone point me to the source code of pythondialog where the 
> keyboardcode is trapped?

I'm afraid this can't be implemented in pythondialog itself. This kind
of thing needs to be implemented in dialog before pythondialog can use
it. Depending on what you want to achieve precisely, that could require
a new dialog exit status with special output when it is used. I suggest
you to discuss this with Thomas Dickey, the dialog maintainer. cf. the
dialog home page:

  http://invisible-island.net/dialog/dialog.html

Regards

-- 
Florent

[Pythondialog-users] Function keys

[Fons v. d. B. - 84-IT BV <fon...@84...>]

Hello All

I want to add Function key support to an application and want to use 
pythondialog.
Can someone point me to the source code of pythondialog where the 
keyboardcode is trapped?

[Pythondialog-users] pythondialog 3.2.1 released

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 3.2.1. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/#news-3.2

For your convenience, here is a text dump of this summary (changes since
version 3.1.0):

Main changes in version 3.2.1

   The main change in version 3.2.1 is an improved tutorial chapter in the
   pythondialog Manual[1].

Main changes in version 3.2.0

   The main changes in version 3.2.0 are:

     * New manual[1] generated with Sphinx[2]. Check it out!

     * The default values for day, month and year in the calendar widget
       have been changed from 0 to -1. This is unfortunately
       BACKWARD-INCOMPATIBLE, but 0 doesn't work well for day and month in
       dialog, and it would be quite unintuitive to have them default to
       -1 with the year still defaulting to 0.

       This change should affect very few people, if any, which is why I
       decided to fix the API now without increasing the major version
       number.

For a more detailed description of the changes, you can refer to the
history in the Git repository[3] or the ChangeLog file in a release
tarball.


References

   1. http://pythondialog.sourceforge.net/doc/
   2. http://sphinx-doc.org/
   3. https://sourceforge.net/p/pythondialog/code/

-- 
Florent

[Pythondialog-users] pythondialog 3.1.0 released

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 3.1.0. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/#news-3.1

For your convenience, here is a text dump of this summary:

Main changes in version 3.1.0

  * Experimental support for automatic widget size

    The Dialog class constructor accepts a new keyword-only argument:
    autowidgetsize. It is a boolean and currently defaults to False in
    order to preserve backward-compatibility.

    When set to True, pythondialog's widget-producing methods will
    behave as if width=0, height=0, etc. had been passed, except where
    these parameters are explicitely specified with different values.
    This has the effect that, except where you explicitely specify a
    size parameter such as width or height, the dialog backend will
    automatically compute a suitable widget size for you.

    Notes:

       + In order to differentiate between a default value obtained
         when autowidgetsize is disabled and an explicitely-specified
         width, height, etc., the size parameters modified by this
         change now default to None. In order to compensate for this
         information loss, the effective default values when
         autowidgetsize is False are now mentioned in the docstrings of
         the corresponding widget-producing methods.

       + The autowidgetsize option is currently marked as experimental.
         It may default to True in the next major release; please give
         some feedback on the [7]mailing list if you care.

       + You may encounter questionable results if you only set one of
         the width and height parameters to 0 for a given widget (seen
         in dialog 1.2-20140219).

    Examples using the autowidgetsize option can be found in the
    examples/with-autowidgetsize directory of the pythondialog
    distribution.

  * Improved installation instructions

  * Removal of _create_temporary_directory() in favor of
    tempfile.NamedTemporaryFile()

    There was no security problem in _create_temporary_directory() as
    far as I know, however it is usually better to use well-tested
    library functions whenever possible instead of custom ones. When
    _create_temporary_directory() was written, what was available from
    the tempfile module was not satisfactory, but this is not the case
    anymore.

    This change brings a small BACKWARD INCOMPATIBILITY: the
    UnableToCreateTemporaryDirectory exception is not defined anymore.
    Dialog.scrollbox() now creates a temporary file without any
    temporary directory, therefore there is no place anymore for this
    exception to be used. The equivalent condition in
    tempfile.NamedTemporaryFile() generates an OSError exception (more
    precisely, a FileExistsError in Python 3.3 or later, which is a
    subclass of OSError). As usual, this exception is wrapped by
    pythondialog and seen as a PythonDialogOSError by user code.

    Conclusion: wherever user code was expecting
    UnableToCreateTemporaryDirectory in previous versions, it should
    now expect a PythonDialogOSError, consistently with the tempfile
    module and OSError wrapping by pythondialog.

    This incompability should affect so few users, if any, that I think
    increasing the major number just for it would have caused more harm
    than good.

  * The programbox widget has been improved in dialog 1.2-20140112 and
    the demo uses it in a better way.

  * The files demo.py and simple_example.py have been moved to the
    examples directory of the source distribution.

-- 
Florent

[Pythondialog-users] Default width/height/list_height/... for widgets

[Florent R. <f.r...@fr...>]

Hello,

When most of the pythondialog widget bindings were written, the dialog
backend did not work well when using width=0 and height=0 for widgets.
This is why most widgets, with the notable exception of those whose
bindings were recently written, have a non-zero default value in
pythondialog for the width, height and
list_height/menu_height/form_height/etc. parameters. These default
values have been chosen to look fine on a 80×25 terminal, but obviously
can't be adequate for any kind of widget contents.

The situation has changed, however, and current versions of dialog seem
to perform a decent automatic size computation when using 0 for such
parameters. As a consequence, 0 seems to be a better candidate for the
default width/height/etc. than any fixed value. This is why I have used
0 in this context for "recently"-added widgets such as buildlist.

Of course, it would be easy to change all these defaults to 0, but that
would break applications relying on the default values. In order to
allow new applications to use automatic sizing without having to
explicitely write width=0, height=0, and so on in every widget call, I
propose to implement a mechanism similar to Python's __future__
statement. From a user code perspective, that would look like this:

  import dialog
  dialog.enable_feature(dialog.Feature.autowidgetsize)
  d = dialog.Dialog()

  # Would behave as if 'width=0' and 'height=0' had been passed
  d.msgbox("Some text")

  # Same as 'width=45' and 'height=0'
  d.msgbox("Some other text", width=45)

I have written a proof of concept which can be found in the attached
patch. It is based on the enum module for the dialog.Feature object.
enum is only part of the standard library in Python 3.4 and (presumably)
later, but the relevant code is safely ignored when enum is not
available. As a consequence, people using old installations should not
encounter any significant regression due to this change. The patch only
adds the new behavior for the following widgets: msgbox, checklist,
infobox, menu and inputbox. However, it is trivial to extend to all
widgets.

The only downside I can see with this approach is that the actual
default values (for the width/height/list_height/etc. parameters of a
given widget) are not part of the function signature anymore since they
depend on whether dialog.Feature.autowidgetsize has been enabled or not.
Therefore, unless duplicated in the docstring, they can't be found using
help() in the interactive Python interpreter. However, with the idea
that the feature may be enabled by default in a future major release,
the default values in currently-released pythondialog versions would
become obsolete and thus not worth to worry about.

Another point that is worth thinking about is the following: in the
proof of concept being discussed here, the _features object used to
record which members of the dialog.Feature enum have been enabled is
defined at module level. I have done so because the general feature
mechanism might be needed at module level for future changes, however
for the particular 'autowidgetsize' feature, it could as well be
implemented at the Dialog class level. The latter might be useful for
applications using several instances of the Dialog class in the same
process... and needing a specific set of features for every such
instance. I believe this case to be too hypothetical to warrant the
sacrifice of losing the ability to use the feature mechanism at module
level, or to justify the complexity of implementing both module-level
and instance-level features.

Finally, 'autowidgetsize' is the best name I could find, but I am open
to suggestions if someone has a better idea.

If you have something to say before this change reaches the Git
repository, please speak now or forever hold your peace. :-)

-- 
Florent

Re: [Pythondialog-users] pythondialog installation issues on raspberry pi

[Florent R. <f.r...@fr...>]

spam_and_junk <spa...@ii...> wrote:

> Thanks to Florent for the help.
>
> Running under python3 with better results.  No idea why it, but it is
> not reccomended for the raspberry's default, hence trying to use 2.7

I wonder where this recommendation comes from... unless you have strong
dependencies that have not been, and can't easily be ported to Python 3.
Do you have a link?

As reminded at:

  https://pypi.python.org/pypi/python2-pythondialog

which you should definitely read, Python 3.0 was released on December 3,
2008. Python 2 is now more or less obsolete... or in end-of-line state,
if you prefer. Just a few links I saw recently about the subject:

  http://legacy.python.org/dev/peps/pep-0404/
  https://lists.debian.org/debian-python/2014/05/msg00037.html
  http://techs.enovance.com/6521/openstack_python3

If you still decide to work with Python 2, you should probably import
many things from the future, as suggested in:

  https://linuxfr.org/users/thom/journaux/la-duree-de-vie-de-python-2-7-encore-repoussee#comment-1532573

Good luck...

-- 
Florent

Re: [Pythondialog-users] pythondialog installation issues on raspberry pi

[spam_and_junk <spa...@ii...>]

Thanks to Florent for the help.

Running under python3 with better results.  No idea why it, but it is 
not reccomended for the raspberry's default, hence trying to use 2.7

cheers
-Antony


On 8/05/14 1:12 AM, Florent Rougon wrote:
> Hello,
>
> spam_and_junk <spa...@ii...> wrote:
>
>> Hi all,
>>
>> I have no Idea what I'm doing with this list, so apologies for whomever
>> this goes to.
>
> You are at the right place. :-)
>
>> There was an answer poeted on the Raspberry Pi forum regarding
>> installation problems with pythondialog.
>
> Yup.
>
>> Thanks to the author for doing so.
>>
>> I have posted more detailed information there
>> http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=76163&p=546152#p546152
>>
>> the same error arises when trying to run setup.py locally.
>
> For the benefits of other readers, here is what you tried:
>
> ------------------------------------------------------------------------
> pi@raspberrypi ~ $ pip install pythondialog
> Downloading/unpacking pythondialog
>    Downloading pythondialog-3.0.1.tar.bz2 (72kB): 72kB downloaded
>    Running setup.py (path:/tmp/pip_build_pi/pythondialog/setup.py) egg_info for package pythondialog
>      Traceback (most recent call last):
>        File "<string>", line 17, in <module>
>        File "/tmp/pip_build_pi/pythondialog/setup.py", line 39
>          print(traceback.format_exc(), file=sys.stderr)
>                                            ^
>      SyntaxError: invalid syntax
>      Complete output from command python setup.py egg_info:
> ------------------------------------------------------------------------
>
> The basic problem causing the error is that you are trying to install
> the "normal pythondialog", which only supports Python 3, using a pip
> running under Python 2 (2.7 according to your logs). The print()
> function in the above error only exists as a function in Python 3, and
> the pip executable you invoked is running under Python 2.x (in Python 2,
> print is a statement and uses a different syntax).
>
> [ Before describing various possibilities to perform the installation,
>    if you only want to try pythondialog, you can do so without installing
>    it. Simply go to the base source directory obtained from the tarball
>    (the one containing dialog.py and demo.py) and run demo.py with the
>    appropriate Python interpreter. Thus, if you have for instance
>    Python 3.4, you can download pythondialog from
>    https://pypi.python.org/pypi/pythondialog and run:
>
>      python3.4 demo.py
>
>    from the directory obtained after unpacking. If you only have
>    Python 2, let's say 2.7, you should instead download from
>    https://pypi.python.org/pypi/python2-pythondialog and run:
>
>      python2.7 demo.py
>
>    from the base source directory. ]
>
> First, you have to decide which version of Python you want to use for
> your developments and choose the appropriate pip executable accordingly.
> 'pip' is not explicit, but if for instance you have installed pip for
> Python 3.3, you can usually invoke pip-3.3 to be explicit about what you
> want.
>
> Since you appear to be using Debian or one of its derivatives, you can
> do:
>
>    dpkg -S $(which pip)
>
> or:
>
> % dpkg -S /usr/bin/pip
> python-pip: /usr/bin/pip
>
> to find out which Debian package the pip executable comes from (here,
> 'python-pip'). In my case:
>
> % dpkg -S $(which pip)
> dpkg-query: no path found matching pattern /usr/local/bin/pip
>
> because I installed pip manually under /usr/local. If the package is
> 'python-pip', then:
>
> % dpkg -s python-pip | grep ^Version:
> Version: 1.1-3
>
> shows the version of this package (which corresponds to pip 1.1) and,
> more importantly:
>
> % dpkg -s python-pip | grep ^Depends:
> Depends: python2.6, python (>= 2.6.6-7~), python (<< 2.8), python-pkg-resources, python-setuptools (>= 0.6c1)
>
> which shows that this pip package is supposed to work with Python 2.6
> and 2.7 (the '<<' means 'strictly lower than'). It is not quite precise
> however, so we can do:
>
> % /usr/bin/pip --version
> pip 1.1 from /usr/lib/python2.7/dist-packages (python 2.7)
> % ls -l /usr/bin/pip
> lrwxrwxrwx 1 root root 7 Jun 23  2012 /usr/bin/pip -> pip-2.7
>
> to remove any ambiguity. In practice, better use things like pip-2.7
> whenever possible.
>
> Now, if you want to install for Python 3.3 for instance, the command
> could be:
>
>    pip-3.3 install pythondialog
>
> but if you chose to work with the obsolete Python 2, then you would
> need the Python 2 backport of pythondialog instead, as explained at
> http://pythondialog.sourceforge.net/ which could be installed with:
>
>    pip-2.7 install python2-pythondialog
>
> for instance. The first command downloads from:
>
>    https://pypi.python.org/pypi/pythondialog
>
> whereas the second command downloads from:
>
>    https://pypi.python.org/pypi/python2-pythondialog
>
> BUT the command has to be run in a way that gives pip the appropriate
> permissions to do the installation! There are several possibilities for
> this:
>
>    1) Run it as root, but keep in mind that Debian Python folks don't
>       like that. Without more arguments, it should install under
>       /usr/local/lib/python2.7/dist-packages on Debian or under
>       /usr/local/lib/python3.3/site-packages more commonly, or simply if
>       you installed Python manually under /usr/local (version numbers to
>       be adapted, of course).
>
>    2) Create a virtualenv as explained at
>       https://virtualenv.pypa.io/ and install your Python packages in
>       this isolated environment. It is very easy, doesn't require root
>       access, allows you to have several environments with possibly
>       different Python versions and/or combinations of packages. I
>       believe recent versions of Python (3.4 and maybe also 3.3) come
>       with a kind of built-in virtual environment implementation
>       (pyvenv...), but I have not tried this yet.
>
>       Note: when you have a virtualenv in <venv_dir>, <venv_dir>/bin/pip
>       is always the right executable to use to install in that virtual
>       environment (no need to pay attention to the Python version in that
>       case, no need to 'activate' the environment unless you want to be
>       able to simply type 'pip' in order to invoke the pip from the
>       virtualenv).
>
>    3) Run pip with the --user option, as in:
>
>         pip-3.3 install --user pythondialog
>
>       which should install, with default settings, under:
>
>         ~/.local/lib/python3.3/site-packages
>         ~/.local/bin
>         ...
>
>       as explained at:
>
>         https://pip.pypa.io/en/latest/user_guide.html#user-installs
>
>       and:
>
>         https://docs.python.org/3/install/index.html#inst-alt-install-user
>
>       Debian Python people seem to like that, *but*:
>         - it is less flexible than virtualenvs, of which you can create
>           as many as you wish;
>         - uninstallation with the pip available in Debian wheezy silently
>           fails! (this is with --user, normal uninstallations work well
>           AFAICT)
>
> I hope these guidelines will be sufficient for you to succeed with the
> installation. By the way, if the 'setup.py install' method also failed,
> it is probably for the same reasons:
>    - using a Python 2.x interpreter with the "normal pythondialog", as
>      opposed to the Python 2 backport;
>    - trying to install as a normal user to a place where writing requires
>      root privileges.
>
>> Excuse my ignorarance, the pi is my first foray into both linux and
>> python (usually embedded c++ on PIC/Atmel AVR)
>
> OK, no problem. Please follow up on this mailing list
> (pythondialog-users), as your question doesn't seem to be specific to
> the Raspberry Pi.
>

Re: [Pythondialog-users] pythondialog installation issues on raspberry pi

[Florent R. <f.r...@fr...>]

Hello,

spam_and_junk <spa...@ii...> wrote:

> Hi all,
>
> I have no Idea what I'm doing with this list, so apologies for whomever 
> this goes to.

You are at the right place. :-)

> There was an answer poeted on the Raspberry Pi forum regarding 
> installation problems with pythondialog.

Yup.

> Thanks to the author for doing so.
>
> I have posted more detailed information there 
> http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=76163&p=546152#p546152
>
> the same error arises when trying to run setup.py locally.

For the benefits of other readers, here is what you tried:

------------------------------------------------------------------------
pi@raspberrypi ~ $ pip install pythondialog
Downloading/unpacking pythondialog
  Downloading pythondialog-3.0.1.tar.bz2 (72kB): 72kB downloaded
  Running setup.py (path:/tmp/pip_build_pi/pythondialog/setup.py) egg_info for package pythondialog
    Traceback (most recent call last):
      File "<string>", line 17, in <module>
      File "/tmp/pip_build_pi/pythondialog/setup.py", line 39
        print(traceback.format_exc(), file=sys.stderr)
                                          ^
    SyntaxError: invalid syntax
    Complete output from command python setup.py egg_info:
------------------------------------------------------------------------

The basic problem causing the error is that you are trying to install
the "normal pythondialog", which only supports Python 3, using a pip
running under Python 2 (2.7 according to your logs). The print()
function in the above error only exists as a function in Python 3, and
the pip executable you invoked is running under Python 2.x (in Python 2,
print is a statement and uses a different syntax).

[ Before describing various possibilities to perform the installation,
  if you only want to try pythondialog, you can do so without installing
  it. Simply go to the base source directory obtained from the tarball
  (the one containing dialog.py and demo.py) and run demo.py with the
  appropriate Python interpreter. Thus, if you have for instance
  Python 3.4, you can download pythondialog from
  https://pypi.python.org/pypi/pythondialog and run:

    python3.4 demo.py

  from the directory obtained after unpacking. If you only have
  Python 2, let's say 2.7, you should instead download from
  https://pypi.python.org/pypi/python2-pythondialog and run:

    python2.7 demo.py

  from the base source directory. ]

First, you have to decide which version of Python you want to use for
your developments and choose the appropriate pip executable accordingly.
'pip' is not explicit, but if for instance you have installed pip for
Python 3.3, you can usually invoke pip-3.3 to be explicit about what you
want.

Since you appear to be using Debian or one of its derivatives, you can
do:

  dpkg -S $(which pip)

or:

% dpkg -S /usr/bin/pip
python-pip: /usr/bin/pip

to find out which Debian package the pip executable comes from (here,
'python-pip'). In my case:

% dpkg -S $(which pip)
dpkg-query: no path found matching pattern /usr/local/bin/pip

because I installed pip manually under /usr/local. If the package is
'python-pip', then:

% dpkg -s python-pip | grep ^Version:
Version: 1.1-3

shows the version of this package (which corresponds to pip 1.1) and,
more importantly:

% dpkg -s python-pip | grep ^Depends:
Depends: python2.6, python (>= 2.6.6-7~), python (<< 2.8), python-pkg-resources, python-setuptools (>= 0.6c1)

which shows that this pip package is supposed to work with Python 2.6
and 2.7 (the '<<' means 'strictly lower than'). It is not quite precise
however, so we can do:

% /usr/bin/pip --version
pip 1.1 from /usr/lib/python2.7/dist-packages (python 2.7)
% ls -l /usr/bin/pip
lrwxrwxrwx 1 root root 7 Jun 23  2012 /usr/bin/pip -> pip-2.7

to remove any ambiguity. In practice, better use things like pip-2.7
whenever possible.

Now, if you want to install for Python 3.3 for instance, the command
could be:

  pip-3.3 install pythondialog

but if you chose to work with the obsolete Python 2, then you would
need the Python 2 backport of pythondialog instead, as explained at
http://pythondialog.sourceforge.net/ which could be installed with:

  pip-2.7 install python2-pythondialog

for instance. The first command downloads from:

  https://pypi.python.org/pypi/pythondialog

whereas the second command downloads from:

  https://pypi.python.org/pypi/python2-pythondialog

BUT the command has to be run in a way that gives pip the appropriate
permissions to do the installation! There are several possibilities for
this:

  1) Run it as root, but keep in mind that Debian Python folks don't
     like that. Without more arguments, it should install under
     /usr/local/lib/python2.7/dist-packages on Debian or under
     /usr/local/lib/python3.3/site-packages more commonly, or simply if
     you installed Python manually under /usr/local (version numbers to
     be adapted, of course).

  2) Create a virtualenv as explained at
     https://virtualenv.pypa.io/ and install your Python packages in
     this isolated environment. It is very easy, doesn't require root
     access, allows you to have several environments with possibly
     different Python versions and/or combinations of packages. I
     believe recent versions of Python (3.4 and maybe also 3.3) come
     with a kind of built-in virtual environment implementation
     (pyvenv...), but I have not tried this yet.

     Note: when you have a virtualenv in <venv_dir>, <venv_dir>/bin/pip
     is always the right executable to use to install in that virtual
     environment (no need to pay attention to the Python version in that
     case, no need to 'activate' the environment unless you want to be
     able to simply type 'pip' in order to invoke the pip from the
     virtualenv).

  3) Run pip with the --user option, as in:

       pip-3.3 install --user pythondialog

     which should install, with default settings, under:

       ~/.local/lib/python3.3/site-packages
       ~/.local/bin
       ...

     as explained at:

       https://pip.pypa.io/en/latest/user_guide.html#user-installs

     and:

       https://docs.python.org/3/install/index.html#inst-alt-install-user

     Debian Python people seem to like that, *but*:
       - it is less flexible than virtualenvs, of which you can create
         as many as you wish;
       - uninstallation with the pip available in Debian wheezy silently
         fails! (this is with --user, normal uninstallations work well
         AFAICT)

I hope these guidelines will be sufficient for you to succeed with the
installation. By the way, if the 'setup.py install' method also failed,
it is probably for the same reasons:
  - using a Python 2.x interpreter with the "normal pythondialog", as
    opposed to the Python 2 backport;
  - trying to install as a normal user to a place where writing requires
    root privileges.

> Excuse my ignorarance, the pi is my first foray into both linux and
> python (usually embedded c++ on PIC/Atmel AVR)

OK, no problem. Please follow up on this mailing list
(pythondialog-users), as your question doesn't seem to be specific to
the Raspberry Pi.

-- 
Florent

[Pythondialog-users] pythondialog instalation issues on raspberry pi

[spam_and_junk <spa...@ii...>]

Hi all,

I have no Idea what I'm doing with this list, so apologies for whomever 
this goes to.

There was an answer poeted on the Raspberry Pi forum regarding 
installation problems with pythondialog.

Thanks to the author for doing so.

I have posted more detailed information there 
http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=76163&p=546152#p546152

the same error arises when trying to run setup.py locally.

Excuse my ignorarance, the pi is my first foray into both linux and 
python (usually embedded c++ on PIC/Atmel AVR)

Thanks

[Pythondialog-users] pythondialog 3.0.1 released with Python 2 backport

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 3.0.1. For Python 3
users, it only has minor improvements compared to version 3.0.0.
However, for Python 2 users, this release comes with a Python 2 backport
available on PyPI under the name python2-pythondialog:

  https://pypi.python.org/pypi/python2-pythondialog

Be sure to read the backport-specific notes on that page before
installing the backport (in short: it has full support for Unicode
strings and no support for byte strings, which is the opposite situation
as that offered by versions 2.11 and earlier).

In the Git repository, the Python 2 backport corresponds to the 'py2'
branch, while the 'master' branch remains the reference implementation,
i.e., for Python 3 for the time being and the forseeable future.

For your convenience, here follows the ChangeLog excerpt between
versions 3.0.0 and 3.0.1 (from the 'master' branch):

2013-10-27  Florent Rougon

        Make sure ChangeLog.init and ChangeLog are read/written using UTF-8

        * setup.py: make sure ChangeLog.init and ChangeLog are read/written
        using UTF-8 (regardless of locale settings), consistently with the Git
        repository and release tarballs.

2013-10-18  Florent Rougon

        Minor improvements

        * dialog.py (Dialog.backend_version): when raising
        UnableToRetrieveBackendVersion, print the exit code (which is now a
        string) with repr()-style representation.

        * demo.py:
            - use the print() function instead of sys.stderr.write();
            - minor improvement of the buildlist demo.

        * setup.py:
            - add "ncurses" and "terminal" as keywords;
            - use a 'with' statement to open and close 'README.rst'.

        * README.rst: mainly, write appropriate text concerning the Python 2
        backport.

-- 
Florent

[Pythondialog-users] pythondialog 3.0.0 released

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 3.0.0. You can read
a summary of the changes in this version at:

  http://pythondialog.sourceforge.net/#news-3.0

For your convenience, here is a text dump of this summary:

Main changes in version 3.0.0

   The major version number has been increased because this version is not
   completely backward-compatible with version 2. However, the
   backward-incompatible changes are small and unlikely to affect many
   people, if any (see below). The main changes in version 3.0.0 are:

     * Full help support for all widgets

       You can now use the keyword arguments (“dialog common options”)
       help_button, help_label, item_help, help_tags and help_status with
       any widget to provide help facilities to the user (as long as the
       dialog backend supports the corresponding options). Please refer to
       the Dialog class docstring in the [10]documentation for details.
       demo.py has a number of examples showing how to implement help
       support in user code.
       The API extends what was already present for help support in the
       'menu' widget. Backward-compatibility is only affected for people
       who used to parse the dialog output after the Help button has been
       pressed, because this is now automatically done by pythondialog in
       order to return ready to use, structured data. If you only check
       the Dialog exit code, you are not affected.
       pythondialog should now offer access to all help facilities
       provided by the dialog backend.

     * Nicer exit codes for widget-producing methods

       The old, low-level exit codes d.DIALOG_OK, d.DIALOG_CANCEL,
       d.DIALOG_ESC, d.DIALOG_HELP, d.DIALOG_ITEM_HELP and d.DIALOG_EXTRA
       are deprecated (where d is a Dialog instance). They still work, but
       trigger a DeprecationWarning (see README.rst or [11]its HTML
       rendering for instructions on how to enable deprecation warnings).
       You should now use d.OK, d.CANCEL, d.ESC, d.HELP and d.EXTRA, or
       equivalently Dialog.OK, Dialog.CANCEL, Dialog.ESC, Dialog.HELP and
       Dialog.EXTRA (attributes of the Dialog class). These are called the
       high-level exit codes, or Dialog exit codes, and defined as
       strings: "ok", "cancel", "esc", "help" and "extra". You should use
       the == operator when comparing to these codes.

       Notes:

          + There is no ITEM_HELP in the high-level exit codes: the
            DIALOG_HELP and DIALOG_ITEM_HELP low-level codes are both
            translated into Dialog.HELP. Indeed, the program that has to
            interpret the code already knows whether it used
            item_help=True in the widget call or not. Both cases
            correspond to the same user action: the Help button being
            pressed. Therefore, the distinction is not useful to user
            code.

          + As said, the values of the high-level exit codes are strings:
            "ok", "cancel", "esc", "help" and "extra". You may use the
            string literals directly in your code, instead of d.OK or
            Dialog.OK, d.CANCEL or Dialog.CANCEL, etc. With proper syntax
            highlighting, this produces good-looking code, but offers no
            protection against typos, contrary to the Dialog class
            attributes Dialog.OK and friends. Apart from that, it is
            mostly a matter of taste.

          + Backward-compatibility should only be affected for code that
            relies on the nature of d.DIALOG_OK, d.DIALOG_CANCEL,
            d.DIALOG_ESC, d.DIALOG_HELP, d.DIALOG_ITEM_HELP and
            d.DIALOG_EXTRA, which were integers in pythondialog 2 and are
            now strings (the deprecated attributes are mapped to the
            high-level exit codes, so that the vast majority of old user
            code still works without modification, despite the changes).

     * Better Extra button support

          + A few widgets, when the Extra button was pressed, used to
            return None instead of the expected value corresponding to
            user input. This is fixed.

          + Similarly to help support, pythondialog now automatically
            parses the dialog output when the Extra button has been
            pressed, in order to return ready to use, structured data
            (normally: the same as if OK had been pressed). This is
            backward-incompatible.

       Extra button support should now be as good as in the dialog
       backend. See the Dialog class docstring for details.

     * 'buildlist' widget support

     * New retval_is_code decorator that sets the attribute of the same
       name on its argument. This attribute allows to reliably detect if a
       widget-producing method returns a Dialog exit code or a sequence
       whose first element is a Dialog exit code. This is used in the
       demo, and was necessary since the new exit codes from
       widget-producing methods are strings, and thus sequences.

-- 
Florent

[Pythondialog-users] pythondialog 2.14.1 released

[Florent R. <f.r...@fr...>]

Hello,

pythondialog 2.14.1 has been released. A summary of the changes can be
found at:

  http://pythondialog.sourceforge.net/#news-2.14

A more detailed version, reproduced here for your convenience, can be
found in the ChangeLog:

2013-10-01  Florent Rougon

	Fixes for the programbox demo

	* demo.py (programbox_demo): the programbox demo (only run in
	--test-suite mode) uses subprocess.DEVNULL, which was added in Python
	3.3. Provide an alternate method when this feature is not available.

	* demo.py (programbox_demo): close the pipe used to communicate with
	dialog when it is not needed anymore (otherwise, running the demo with
	warnings enabled [python3 -Wd demo.py 2>/path/to/file] shows a
	ResourceWarning).

2013-10-01  Florent Rougon

	Better reporting of dialog errors

	* dialog.py: when dialog exits with status DIALOG_ERROR, write its
	output as part of the DialogError exception that is raised. This should
	make it much easier to understand the cause of errors. This requires
	reading the dialog output before wait()ing for it to exit, which is a
	good thing in any case, as big amounts of output could cause a kind of
	deadlock, since dialog would be blocked with its output pipe full while
	we would be wait()ing for it to exit.

2013-09-30  Florent Rougon

	Easier management of the ChangeLog file

	* Rename ChangeLog to ChangeLog.init and modify setup.py to
	automatically generate, when invoked, an up-to-date ChangeLog file with
	the oldest entries from ChangeLog.init and the newest ones from the Git
	log.

	* README.distributors: new file explaining this mechanism and how to
	prepare a package (or new release) from the Git repository.

2013-09-26  Florent Rougon

	Decorate Dialog.form with the 'widget' decorator

	* dialog.py: in commit cfcf412d86c5d8daebcf004d4e9fe02ecbb881b3, it was
	forgotten to use the 'widget' decorator on Dialog.form. This commit
	fixes this bug.

2013-09-20  Florent Rougon

	Clarify the rules concerning the 'widget' decorator

	* dialog.py: be more precise about the interface that must be offered by
	methods decorated with the 'widget' decorator (and therefore having the
	'is_widget' attribute). Also, don't use the "widget-producing"
	expression to qualify methods that are not eligible for this decorator
	(such as Dialog.gauge_update()).

	* demo.py: similar precisions.

-- 
Florent

[Pythondialog-users] pythondialog 2.14.0 released

[Florent R. <f.r...@fr...>]

Hello,

I am pleased to announce the release of pythondialog 2.14.0 (as you may
have noticed, from version 2.13.1 onwards, pythondialog version numbers
have three components, with a similar policy as for CPython, albeit on a
tremendously smaller scale).

After having sent a mail to "paulproteus" on August 17 (with no reply so
far) and filed a support request at PyPI, I have finally obtained
control over the pythondialog PyPI entry. This implies that you can
install the new pythondialog version with:

  pip install pythondialog

Unfortunately, PyPI refuses tarballs named python3-pythondialog-*,
therefore the files uploaded to PyPI don't have the explicit naming
scheme as on SourceForge, where the Python major version is apparent.

As usual, you can find the full list of changes in the Git history and in
the ChangeLog. The main changes in the latest releases are listed at:

  http://pythondialog.sourceforge.net/index.html#news

For your convenience, here is a text dump of the main changes in
version 2.14.0:

* Add support for the 'programbox', 'rangebox' and 'treeview' widgets.

* Add support for new dialog common options: --default-button and
  --no-tags.

* In dialog.py, use a context manager to factor out OSError and IOError
  handling throughout the module.

* dialog.py has a new version_info module-level attribute, similar to
  what the sys module provides. This avoids the need to parse
  __version__ when one wants to extract for instance the major and/or
  minor version number of pythondialog.

* Backend version caching and comparing

  Slight modification to a recent API: when the dialog-like backend does
  not return DIALOG_OK, Dialog.backend_version() raises
  UnableToRetrieveBackendVersion (new exception) instead of returning
  None. This way, the method either returns a string or raises an
  exception.

  dialog.py has a new DialogBackendVersion class (and BackendVersion
  abstract base class) for parsing the version string of the dialog
  backend, storing it in a structured format, and providing easy and
  reliable comparisons between versions using the standard comparison
  operators (<, <=, ==, !=, >=, >).

  Dialog.__init__ retrieves the backend version and stores the
  corresponding (Dialog)BackendVersion instance into a public
  cached_backend_version attribute. This should avoid having to run
  'backend --print-version' every time someone needs the version.

* Check for too old versions of the backend

  dialog.py has a new exception called InadequateBackendVersion that is
  raised when the user tries to use a programbox, rangebox or treeview
  widget with a dialog version that does not implement the widget in
  question (of course, similar checks will be added for future widgets).

  Similarly, for the latest widgets added to dialog, the demo checks the
  version of the backend if it's dialog and displays an explanation
  instead of the widget demo when it is too old.

* Add an 'is_widget' attribute to Dialog widget-producing methods

  dialog.widget is a new decorator to mark the Dialog methods that
  provide a widget. As explained in the docstring, this allows code to
  perform automatic operations on these specific methods. For instance,
  one can define a class that behaves similarly to Dialog, except that
  after every widget-producing call, it spawns a "confirm quit" dialog
  if the widget returned DIALOG_ESC, and loops in case the user doesn't
  actually want to quit.

* Improve structure and ESC handling in the demo

     * New MyApp class that implements the core of the demo. This class
       relies on a new MyDialog class that automatically wraps every
       widget-producing method of dialog.Dialog in order to display the
       "confirm quit" dialog if the user presses the Escape key or the
       Cancel button. This class also provides a few dialog-related
       methods used in the demo.
     * This new structure should completely fix handling of the Escape
       key, which was not satisfactory in previous versions since it
       required a while loop for every widget call that made the code
       redundant and harder to read. The new wrapping mechanism is
       completely transparent for most of the code in MyApp, which thus
       becomes shorter, more reliable and easier to read. The "magic" is
       contained within the MyDialog class.
* Add a sample program called simple_example.py that is really intended
  for newcomers: short, straightforward, with absolutely no magic.

* In demo.py, move a bunch of widget demos from
  MyApp.additional_widgets() to the main MyApp.demo() method to give
  them more visibility. The remaining widgets in
  MyApp.additional_widgets() either have little warts (like programbox
  which is waiting for a fix in the dialog backend), are cumbersome for
  the person running the demo (this is the case of
  progressbox_demo_with_filepath), or are almost identical to widgets
  already presented in the main part of the demo.


PS: the buildlist widget is only waiting for a fix in dialog (bug
    already reported), where --buildlist is not compatible with
    --separate-output.

-- 
Florent

Re: [Pythondialog-users] New pythondialog releases, Python 3 support, git repository, improved web site

[Florent R. <f.r...@fr...>]

Hello,

I've found that the "prefix=/usr/local" setting in setup.cfg breaks
installations with pip inside a virtualenv (at least). I'll release
2.13.1 shortly with this setting removed and some demo improvements
(cf. git repos).

-- 
Florent

[Pythondialog-users] New pythondialog releases, Python 3 support, git repository, improved web site

[Florent R. <f.r...@fr...>]

Dear users,

I am pleased to announce the releases of pythondialog 2.12 and 2.13
(yes, like Halley's Comet). In order to avoid confusion like there has
been in the past, and thanks to the prompt cooperation of Peter Åstrand,
I am now maintaining pythondialog at SourceForge, at the same place
where the old 1.0 and 2.7 releases were uploaded.

The new releases add Python 3 support, a few improvements (actually,
many improvements if you didn't upgrade after version 2.7), and close
all SourceForge bugs. Moreover, you can now follow pythondialog's
development with its git repository[1] and easily compare[2] between
/any/ version ever released, as I incorporated all history back to
version 1.0 in this git repository.

  [1] http://sourceforge.net/p/pythondialog/code/

  [2] git clone git://git.code.sf.net/p/pythondialog/code pythondialog
      cd pythondialog       # and then for instance:
      git diff v2.12 v2.13

I also revamped the website[3]. Please tell me if you find any error. I
hope it looks nicer this way. Additionally, it is now up-to-date and
contains a "Screenshots" page with a picture of every widget supported
in pythondialog, so that you can quickly and easily see what is
available and how it looks like.

  [3] http://pythondialog.sourceforge.net/

If you want to read about the main changes in versions 2.12 and 2.13,
you can find them right there on the main page. Alternatively, I've
copy/pasted a plain text rendering of these changes below for your
convenience.

Finally, a quick link to the download page for the impatient:

  <http://sourceforge.net/projects/pythondialog/files/pythondialog/>

Ah, err... this reminds me that the PyPI[4] entry for pythondialog is
still referencing and distributing version 2.7 only, effectively hiding
all subsequent versions for many users, thanks to our dear friend
"paulproteus" who had the brilliant idea of opening this PyPI entry
under his own account. For this reason, none of the past or present
pythondialog maintainers can update this page! I have tried to contact
him about this (with a Google search for the email address, since PyPI
doesn't give any), with no luck so far. Ugh. If anyone of you know him,
please get in touch with him. Next step is to file a support request at
PyPI.

  [4] https://pypi.python.org/pypi/pythondialog/


-----------------------------------
Main changes in the latest releases
-----------------------------------

  [ What follows is a plain text dump of
    <http://pythondialog.sourceforge.net/index.html#news>.

    For more detailed changes, please refer to the ChangeLog file in a
    release tarball or use "git log" from the git repository (you can
    also read the same log online at the address [1] mentioned above,
    after following the "History" link). ]

   In short, the latest versions (2.12 and 2.13) only support Python 3; users
   who really want to stick to Python 2 should use version 2.11 for now. The
   naming of each tarball clearly indicates which major version of Python it
   has been prepared for.


  Main changes in version 2.13
  ****************************

   The main changes in version 2.13 are:

     * a new set_background_title() method (replacing the long-obsolete
       setBackgroundTitle() from pythondialog 1.0) that does proper "dash
       escaping"[5];

     * documentation improvements for the Dialog class.

       [5] This could be useful if you (somewhat strangely) chose a
           backtitle that starts with a double dash ("--"). Without dash
           escaping, it might be mistaken for a dialog option.


  Main changes in version 2.12
  ****************************

   The main changes in version 2.12 are:

     * Python 3 support. You can (and should) now pass "normal" strings to
       pythondialog calls, which correspond to Unicode strings in
       Python 2-speak. Python will automatically encode the arguments
       according to the current locale when calling dialog.
       pythondialog-based scripts can be written in any encoding (using an
       encoding declaration if the encoding is not UTF-8), and everything
       will be automatically recoded according to the user's locale when he
       runs the script.

       Of course, if the script tries to display a character that can't be
       represented in the user's locale, there is a problem. For instance,
       the "Y" (LATIN CAPITAL LETTER Y WITH DIAERESIS) and euro sign don't
       exist in ISO 8859-1, therefore if the terminal is running under a
       locale based on ISO 8859-1, it can't display any of these characters
       and there is nothing that pythondialog can do about that. However, if
       using only characters that can be represented in the user's locale,
       there is no problem and everything is automatically translated between
       the encoding of the Python script and the encoding defined by the
       user's locale. In particular, this last condition is almost always
       satisfied when the user's locale is based on Unicode, since this
       character set can represent just about anything that can be found in
       the myriad of legacy character sets.

     * Proper escaping of user-supplied values in case they start with two
       dashes ("--"). Such strings could be confused with dialog options in
       previous versions, since pythondialog didn't do any such escaping
       before version 2.12.

     * Much easier debugging, with Dialog.setup_debug(), its optional use in
       the demo and the new traceback handling thanks to the traceback module
       (see the documentation, history link on the git repository, or
       ChangeLog file in a release tarball for details). In case there is a
       problem with the demo, or if you just want to look under the hood, you
       can now run it with --debug (and optionally --debug-file) to make it
       write the full dialog command lines to a file.

     * Standard exception behavior: if e is a dialog.error instance (or an
       instance of a dialog.error subclass), then str(e) returns nothing more
       than the exception message, as with all Python built-in exceptions. No
       need to write e.complete_message() anymore.

     * Support for many "common options" has been added: --ascii-lines,
       --colors, --column-separator, --date-format, --exit-label,
       --extra-button, --extra-label, --hfile, --hline, --keep-tite,
       --keep-window, --no-collapse, --no-lines, --no-mouse, --no-nl-expand,
       --no-ok, --scrollbar, --time-format, --trace and --visit-items. The
       new method Dialog.maxsize() allows one to find the terminal size and
       know how many lines and columns are available for a dialog box.

     * The pythondialog version is now accessible as dialog.__version__
       (attribute of the dialog module), as per Python standards;
       additionally, the version of the dialog backend in use can be obtained
       with Dialog.backend_version() (method of Dialog instances).

     * Transition from PythonDialogIOError to PythonDialogOSError. As you may
       be aware of, the exception hierarchy has been reworked in Python 3.3,
       and from this version onwards, IOError is an alias of OSError. In this
       context, it would be nice to get rid of PythonDialogIOError in favor
       of PythonDialogOSError. pythondialog 2.12 prepares this transition in
       the following way.

       PythonDialogIOError is now a subclass of PythonDialogOSError so that
       users can safely replace "except PythonDialogIOError" clauses with
       "except PythonDialogOSError" even if running under Python < 3.3.
       pythondialog will raise PythonDialogOSError instead of
       PythonDialogIOError when Python stops distinguishing between IOError
       and OSError, i.e. when running under Python 3.3 or later.

-- 
Florent

Re: [Pythondialog-users] Repost: Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Andy D. <an...@no...>]

Hi,

Guys I solved this :

Cast your mind back - I was making a dialog.menu box, and inserting my choices using a database query, like this :

>        cursor.execute ("SELECT id, hostname FROM host WHERE user_id=%s", userid)
>        hostchoices = list(cursor.fetchall())
>        while 1:
>                (code, tag) = d.menu( "Pick a host to manage?",
>                                       width=60,
>                                       choices=hostchoices )


'id' in the database was actually an integer, and this integer type was being preserved into Python.  

dialog.menu requires that tags and items are strings, so I changed this code to literally force the type to string :

def make_menuchoices(raw):
        choicelist = []
        for row in raw:
                tag  = str(row[0])
                item = str(row[1])
                tagitem = tag, item
                choicelist.append(tagitem)
        return choicelist

[...]

        hostchoices = make_menuchoices(cursor.fetchall())

Now, pythondialog is working exactly as you (well, I...) would expect it to.

It would have been more than nice for pythondialog to return some kind of type error, rather than crash with the error message as shown in the subject line.  

Andy

Re: [Pythondialog-users] Repost: Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Andy D. <an...@no...>]

On 9 Jan 2012, at 06:59, Jose Mari wrote:

> I think that in last instance pythondialog runs a shell with dialog cmd.
> 
> In function  _call_program(self, redirect_child_stdin, cmdargs,
> **kwargs) exits the exec command:
> os.execve(self._dialog_prg, arglist, new_environ)
> 
> Try to print the complete line call and test it in a bash shell.

Thanks for the advice.  In the documentation, I found that there was a suggested 'debugging' block of text that caused the command to be written out.  

                import commands
                
                envvar_settings_list = []

                if new_environ.has_key("DIALOGRC"):
                     envvar_settings_list.append(
                         "DIALOGRC='%s'" % new_environ["DIALOGRC"])

                for var in _dialog_exit_status_vars.keys():
                    varname = "DIALOG_" + var
                    envvar_settings_list.append(
                        "%s=%s" % (varname, new_environ[varname]))

                envvar_settings = string.join(envvar_settings_list, " ")

                file("command.debug", "wb").write(
                    envvar_settings +
                    string.join(map(commands.mkarg, arglist), ""))
                os.execve(self._dialog_prg, arglist, new_environ)

When it works ok, I get useful stuff in the output file :

DIALOG_OK=0 DIALOG_HELP=5 DIALOG_EXTRA=4 DIALOG_ESC=2 DIALOG_ERROR=3 DIALOG_CANCEL=1 '/usr/bin/dialog' '--backtitle' 'Welcome to xxxxx' '--menu' 'Where would you like to go today ?' '15' '60' '7' 'AddHost' 'Add Host to System' 'AddCheck' 'Add Check to Host' 'Logout' 'Log out of Shell'

But when I try to build a menu of options from the database as described in my original mail at the top of the thread, the output file is made blank.

-rw-r--r--  1 andy andy    0 Jan 10 17:31 command.debug



On 9 Jan 2012, at 08:18, Peter Åstrand wrote:

> Try running "strace -f" on the entire application.


This is what looks to happen at the time of the crash :

$ strace -f python xxshell.py  1
[...]
[pid 20299] fstat(6, {st_mode=S_IFREG|0644, st_size=2477, ...}) = 0
[pid 20299] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5494054000
[pid 20299] read(6, "\321\362\r\nW\313\27Mc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0sF\0\0\0d\0"..., 4096) = 2477
[pid 20299] fstat(6, {st_mode=S_IFREG|0644, st_size=2477, ...}) = 0
[pid 20299] read(6, "", 4096)           = 0
[pid 20299] close(6)                    = 0
[pid 20299] munmap(0x7f5494054000, 4096) = 0
[pid 20299] close(4)                    = 0
[pid 20299] open("command.debug", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
[pid 20299] fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 20299] close(4)                    = 0
[pid 20299] exit_group(127)             = ?
Process 20296 resumed
Process 20299 detached
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 127}], 0, NULL) = 20299
--- SIGCHLD (Child exited) @ 0 (0) ---
write(2, "Traceback (most recent call last"..., 35Traceback (most recent call last):
) = 35
write(2, "  File \"monshell.py\", line 126, "..., 44  File "monshell.py", line 126, in <module>
) = 44
open("monshell.py", O_RDONLY)           = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=3578, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5494054000
read(5, "import sys, os, os.path, time, s"..., 4096) = 3578
write(2, "    ", 4    )                     = 4
write(2, "if __name__ == \"__main__\": main("..., 34if __name__ == "__main__": main()
) = 34
close(5)                                = 0


Any ideas ?

Andy

Re: [Pythondialog-users] Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Peter Å. <as...@ce...>]

Try running "strace -f" on the entire application.

Rgds,
Peter


On Wed, 4 Jan 2012, Andy Davidson wrote:

>
> Dear pythondialog-users.
>
> Thanks for this software, but please could I request some technical support with regards to an issue I am struggling to debug.  I am trying to produce a dialog.menu and populate the menu with items as discovered in a database.
>
> I see in demo.py that d.menu takes a list of tuples for menu option choices, so this is the data type I am building.
>
> This is the code I am using :
>
> def add_check(d, userid, cursor):
>        cursor.execute ("SELECT id, hostname FROM host WHERE user_id=%s", userid)
>        hostchoices = list(cursor.fetchall())
> #       print hostchoices;
>        while 1:
>                (code, tag) = d.menu( "Pick a host to manage?",
>                                       width=60,
>                                       choices=hostchoices )
>                if handle_exit_code(d, code):
>                        break
>                d.msgbox ("You picked host " . tag)
>        return 0
>
>
>
> When I print hostchoices, I see :
>
> [(1L, 'host1'), (2L, 'host2), (3L, 'host3'), (4L, 'host4'), (6L, 'host6'), (7L, 'host7'), (8L, 'host8')]
>
>
>
>
> It produces this traceback :
>
> Traceback (most recent call last):
>  File "monshell.py", line 126, in <module>
>    if __name__ == "__main__": main()
>  File "monshell.py", line 119, in main
>    main_menu(d, userid, cursor)
>  File "monshell.py", line 98, in main_menu
>    options[tag](d,userid,cursor)
>  File "monshell.py", line 73, in add_check
>    choices=hostchoices )
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 1253, in menu
>
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 825, in _perform
>
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 765, in _wait_for_program_termination
>
> dialog.PythonDialogErrorBeforeExecInChildProcess: <PythonDialogErrorBeforeExecInChildProcess: perhaps the dialog-like program could not be executed; perhaps the system is out of memory; perhaps the maximum number of open file descriptors has been reached>
>
>
> It happens on the Linux and OSX version I have.
>
> Any clues about how I can debug this ?  Dialog is running ok elsewhere in my application - in fact I also use a static menu elsewhere which builds just fine.
>
> Thanks
> Andy
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Pythondialog-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythondialog-users
>


---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

Re: [Pythondialog-users] Repost: Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Jose M. <jos...@gm...>]

On Sun, Jan 8, 2012 at 8:21 PM, Andy Davidson <an...@no...> wrote:
>
>
> Hi there,
>
> Please can I check that this went out? Any ideas?
>
> Andy
>
> Begin forwarded message:
>
> From: Andy Davidson <an...@no...>
> Date: 4 January 2012 14:45:53 GMT
> To: pyt...@li...
> Subject: [Pythondialog-users] Crash!
> dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.
>
>
> Dear pythondialog-users.
>
> Thanks for this software, but please could I request some technical support
> with regards to an issue I am struggling to debug.  I am trying to produce a
> dialog.menu and populate the menu with items as discovered in a database.
>
> I see in demo.py that d.menu takes a list of tuples for menu option choices,
> so this is the data type I am building.
>
> This is the code I am using :
>
> def add_check(d, userid, cursor):
>        cursor.execute ("SELECT id, hostname FROM host WHERE user_id=%s",
> userid)
>        hostchoices = list(cursor.fetchall())
> #       print hostchoices;
>        while 1:
>                (code, tag) = d.menu( "Pick a host to manage?",
>                                       width=60,
>                                       choices=hostchoices )
>                if handle_exit_code(d, code):
>                        break
>                d.msgbox ("You picked host " . tag)
>        return 0
>
>
>
> When I print hostchoices, I see :
>
> [(1L, 'host1'), (2L, 'host2), (3L, 'host3'), (4L, 'host4'), (6L, 'host6'),
> (7L, 'host7'), (8L, 'host8')]
>
>
>
>
> It produces this traceback :
>
> Traceback (most recent call last):
>  File "monshell.py", line 126, in <module>
>    if __name__ == "__main__": main()
>  File "monshell.py", line 119, in main
>    main_menu(d, userid, cursor)
>  File "monshell.py", line 98, in main_menu
>    options[tag](d,userid,cursor)
>  File "monshell.py", line 73, in add_check
>    choices=hostchoices )
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 1253, in menu
>
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 825, in _perform
>
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 765, in
> _wait_for_program_termination
>
> dialog.PythonDialogErrorBeforeExecInChildProcess:
> <PythonDialogErrorBeforeExecInChildProcess: perhaps the dialog-like program
> could not be executed; perhaps the system is out of memory; perhaps the
> maximum number of open file descriptors has been reached>
>
>
> It happens on the Linux and OSX version I have.
>
> Any clues about how I can debug this ?  Dialog is running ok elsewhere in my
> application - in fact I also use a static menu elsewhere which builds just
> fine.
>
> Thanks
> Andy
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Pythondialog-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythondialog-users
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Pythondialog-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythondialog-users
>

I think that in last instance pythondialog runs a shell with dialog cmd.

In function  _call_program(self, redirect_child_stdin, cmdargs,
**kwargs) exits the exec command:
os.execve(self._dialog_prg, arglist, new_environ)

Try to print the complete line call and test it in a bash shell.

Bye

[Pythondialog-users] Repost: Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Andy D. <an...@no...>]

Hi there,

Please can I check that this went out? Any ideas?

Andy

Begin forwarded message:

> From: Andy Davidson <an...@no...>
> Date: 4 January 2012 14:45:53 GMT
> To: pyt...@li...
> Subject: [Pythondialog-users] Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.
> 
> 
> Dear pythondialog-users.
> 
> Thanks for this software, but please could I request some technical support with regards to an issue I am struggling to debug.  I am trying to produce a dialog.menu and populate the menu with items as discovered in a database.
> 
> I see in demo.py that d.menu takes a list of tuples for menu option choices, so this is the data type I am building.
> 
> This is the code I am using :
> 
> def add_check(d, userid, cursor):
>        cursor.execute ("SELECT id, hostname FROM host WHERE user_id=%s", userid)
>        hostchoices = list(cursor.fetchall())
> #       print hostchoices;
>        while 1:
>                (code, tag) = d.menu( "Pick a host to manage?",
>                                       width=60,
>                                       choices=hostchoices )
>                if handle_exit_code(d, code):
>                        break
>                d.msgbox ("You picked host " . tag)
>        return 0
> 
> 
> 
> When I print hostchoices, I see :
> 
> [(1L, 'host1'), (2L, 'host2), (3L, 'host3'), (4L, 'host4'), (6L, 'host6'), (7L, 'host7'), (8L, 'host8')]
> 
> 
> 
> 
> It produces this traceback :
> 
> Traceback (most recent call last):
>  File "monshell.py", line 126, in <module>
>    if __name__ == "__main__": main()
>  File "monshell.py", line 119, in main
>    main_menu(d, userid, cursor)
>  File "monshell.py", line 98, in main_menu
>    options[tag](d,userid,cursor)
>  File "monshell.py", line 73, in add_check
>    choices=hostchoices )
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 1253, in menu
> 
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 825, in _perform
> 
>  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 765, in _wait_for_program_termination
> 
> dialog.PythonDialogErrorBeforeExecInChildProcess: <PythonDialogErrorBeforeExecInChildProcess: perhaps the dialog-like program could not be executed; perhaps the system is out of memory; perhaps the maximum number of open file descriptors has been reached>
> 
> 
> It happens on the Linux and OSX version I have.  
> 
> Any clues about how I can debug this ?  Dialog is running ok elsewhere in my application - in fact I also use a static menu elsewhere which builds just fine.
> 
> Thanks
> Andy
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Pythondialog-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythondialog-users

[Pythondialog-users] Crash! dialog.PythonDialogErrorBeforeExecInChildProcess - Please help to debug.

[Andy D. <an...@no...>]

Dear pythondialog-users.

Thanks for this software, but please could I request some technical support with regards to an issue I am struggling to debug.  I am trying to produce a dialog.menu and populate the menu with items as discovered in a database.

I see in demo.py that d.menu takes a list of tuples for menu option choices, so this is the data type I am building.

This is the code I am using :

def add_check(d, userid, cursor):
        cursor.execute ("SELECT id, hostname FROM host WHERE user_id=%s", userid)
        hostchoices = list(cursor.fetchall())
#       print hostchoices;
        while 1:
                (code, tag) = d.menu( "Pick a host to manage?",
                                       width=60,
                                       choices=hostchoices )
                if handle_exit_code(d, code):
                        break
                d.msgbox ("You picked host " . tag)
        return 0



When I print hostchoices, I see :

[(1L, 'host1'), (2L, 'host2), (3L, 'host3'), (4L, 'host4'), (6L, 'host6'), (7L, 'host7'), (8L, 'host8')]




It produces this traceback :

Traceback (most recent call last):
  File "monshell.py", line 126, in <module>
    if __name__ == "__main__": main()
  File "monshell.py", line 119, in main
    main_menu(d, userid, cursor)
  File "monshell.py", line 98, in main_menu
    options[tag](d,userid,cursor)
  File "monshell.py", line 73, in add_check
    choices=hostchoices )
  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 1253, in menu
    
  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 825, in _perform
    
  File "build/bdist.macosx-10.7-intel/egg/dialog.py", line 765, in _wait_for_program_termination
    
dialog.PythonDialogErrorBeforeExecInChildProcess: <PythonDialogErrorBeforeExecInChildProcess: perhaps the dialog-like program could not be executed; perhaps the system is out of memory; perhaps the maximum number of open file descriptors has been reached>


It happens on the Linux and OSX version I have.  

Any clues about how I can debug this ?  Dialog is running ok elsewhere in my application - in fact I also use a static menu elsewhere which builds just fine.

Thanks
Andy