similar to: [PATCH nbdkit] python: Try harder to print the full traceback on error.

On Wed, Aug 8, 2018 at 4:07 PM Richard W.M. Jones <rjones@redhat.com> wrote: > The tracebacks are compressed into a single line because we're using > PyObject_Str, but they are just about usable if not very readable. > For example you would see an error like this: > > nbdkit: error: ./python-exception.py: config_complete: error: ['Traceback > (most recent call

On 04/05/2018 07:47 AM, Richard W.M. Jones wrote: > --- > configure.ac | 8 +++++++ > plugins/python/python.c | 51 +++++++++++++++++++++++++++++++++++++++--- > tests/Makefile.am | 1 + > tests/python-exception.py | 45 +++++++++++++++++++++++++++++++++++++ > tests/test-python-exception.sh | 42 ++++++++++++++++++++++++++++++++++ >

We used traceback.format_exception, returning traceback lines. Join the lines to make the tracebacks more readable. Here is an example traceback: $ ./nbdkit -f -v python tests/python-exception.py ... nbdkit: debug: python: config_complete nbdkit: error: tests/python-exception.py: config_complete: error: Traceback (most recent call last): File "tests/python-exception.py", line 51, in

Much more annoying that it needs to be, but I have tested it and it works on Python 2 & 3. Note this will not work on Python 3.0 - 3.2, but I guess we don't care about those versions. Rich.

--- configure.ac | 8 +++++++ plugins/python/python.c | 51 +++++++++++++++++++++++++++++++++++++++--- tests/Makefile.am | 1 + tests/python-exception.py | 45 +++++++++++++++++++++++++++++++++++++ tests/test-python-exception.sh | 42 ++++++++++++++++++++++++++++++++++ 5 files changed, 144 insertions(+), 3 deletions(-) diff --git a/configure.ac

Starting with nbdkit 1.16, Python >= 3.3 will be required. Python 2 reaches end of life on 2020-01-01: https://python3statement.org/ https://pythonclock.org/ Debian oldoldstable and RHEL 7 have Python 3.4 and 3.6 respectively, so it seems pointless to try to support Python < 3.3 which lacked support for PyUnicode_AsUTF8. --- README | 13 +++++++------ configure.ac

This patch proposes to drop support for Python 2 in nbdkit. Rather than abruptly drop it everywhere, my proposal is that we point people to nbdkit 1.14 (the current stable version) if they want to continue with Python 2 plugins, while gently reminding them of the upcoming Python 2.7 end of life announcement. Libnbd never supported Python 2. Libguestfs in theory supports Python 2 but I dropped

I''m noticing that my development.log messages are not showing the usual complete logging per request/response when I am catching exceptions from my controllers using rescue_from. I was wondering if anyone has ever encountered this issue before. I''m using Rails 2.2.2. Processing DomainsController#show to xml (for 127.0.0.1 at 2009-04-03 16:41:38) [GET] Parameters:

Fairly straightforward. .list_exports uses the same idiom as .extents for returning an iterable of tuples, with additional support for a bare name rather than a name/desc tuple. .default_export and .export_description are rather easy clients of nbdkit_strdup_intern. Signed-off-by: Eric Blake <eblake at redhat.com> --- plugins/python/nbdkit-python-plugin.pod | 25 ++++ tests/Makefile.am

This picks up python and ocaml. Some of our languages are lacking a number of bindings (for example, lua and perl lack .extents, so I didn't have anything to copy from), and I felt less comfortable with golang and rust. But for python and ocaml, I was able to test a working implementation. Eric Blake (2): python: Implement .list_exports and friends ocaml: Implement .list_exports and

Hi, this series update libguestfs to a recent gnulib version, so that we can use its new getprogname module, and solve altogether one of the porting issues (the need for 'program_name' by the error module of gnulib), and have a single way to get the name of the current program. A number of changes in tools mostly, although mechanical. Thanks, Pino Toscano (3): Update gnulib to latest

Wherever we had code which did: if (something_bad) { perror (...); exit (EXIT_FAILURE); } replace this with use of the error(3) function: if (something_bad) error (EXIT_FAILURE, errno, ...); The error(3) function is supplied by glibc, or by gnulib on platforms which don't have it, and is much more flexible than perror(3). Since we already use error(3), there seems to be

In preparation for adding other optional flag arguments to the python bindings, start by making the existing 'may_trim' flag to 'zero' be optional. That is, the plugin need not define the parameter if it does not make any semantic difference (ie. if the plugin ignores the hint and never trims); while if the parameter exists, we now pass it as a keyword argument rather than as a

In preparation for adding other optional flag arguments to the python bindings, start by making the existing 'may_trim' flag to 'zero' be optional. That is, the plugin need not define the parameter if it does not make any semantic difference (ie. if the plugin ignores the hint and never trims); while if the parameter exists, we now pass it as a keyword argument rather than as a

As mentioned in my reviews, I wonder if we should make our python callbacks look a bit more Pythonic by having kwargs added for each new flag that we want to expose. The idea was first floated here: https://www.redhat.com/archives/libguestfs/2018-April/msg00108.html Note that with my proposal, there is no need for a python script to expose a global API_VERSION variable; new flags are added

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update

First out of our four language bindings to add FUA support (for reference, I added 'zero' support for python, perl, and ruby back in 1.1.13, then Rich had to add it for ocaml in 1.1.20). I tested this heavily under python 2, but for now only compile tested under python 3; I plan to do further testing there and make any tweaks if necessary. I wrote patch 5 early on, but then realized I