From: Phil Muldoon <pmuldoon@redhat.com>
To: andrew@ado.is-a-geek.net
Cc: gdb@sourceware.org
Subject: Re: [PATCH] Allow nested python pretty printers.
Date: Wed, 17 Aug 2011 09:56:00 -0000 [thread overview]
Message-ID: <m3ippw2wfr.fsf@redhat.com> (raw)
In-Reply-To: <1313533386-3222-1-git-send-email-andrew@ado.is-a-geek.net> (andrew@ado.is-a-geek.net's message of "Tue, 16 Aug 2011 23:23:06 +0100")
andrew@ado.is-a-geek.net writes:
> From: Andrew Oakley <andrew@ado.is-a-geek.net>
>
> I don't think this is quite ready to commit - MI support needs to be added and
> documentation needs to be updated. I thought it was sensible to post it now
> though so I can deal with any feedback and so that others don't find the need
> to implement the same thing again.
Understood. If you want comments on a work-in-progress, (I believe) you
should submit it to gdb-patches anyway, with a [RFC] tag.
> By allowing the children iterator of pretty printers to return more
> pretty printers multi levels of display can be created.
I think this idea is ok, but I do not think renaming functions ad-hoc is
ok.
> - try_convert_value_from_python trys to convert a python PyObject to a
> gdb struct value like convert_value_from_python but does not raise an
> error if the PyObject type was not valid.
I think if you want to do this, you should have
try_convert_value_from_python wrap convert_value_from_python and deal
with the exception internally, instead of renaming the function.
> - run_pretty_printer performs all of the steps to print a value given a
The name change seems gratuitous.
> -/* Helper for apply_val_pretty_printer that formats children of the
> - printer, if any exist. If is_py_none is true, then nothing has
> - been printed by to_string, and format output accordingly. */
> +/* Helper for apply_val_pretty_printer that runs a pretty printer,
> + including formattin of the children if any exist. */
Typo formattin.
> static void
> -print_children (PyObject *printer, const char *hint,
> - struct ui_file *stream, int recurse,
> - const struct value_print_options *options,
> - const struct language_defn *language,
> - int is_py_none)
> +run_pretty_printer (PyObject *printer, struct ui_file *stream, int recurse,
> + const struct value_print_options *options,
> + const struct language_defn *language,
> + struct gdbarch *gdbarch)
I'm not sure I agree with name change. I don't want to bike-shed this
but "print_children" is a legitimate atomic operation that should remain
as its own function. I would suggest architecting another function to
call the relevant pieces if we detect nested printers.
> if (!iter)
> @@ -634,15 +645,33 @@ print_children (PyObject *printer, const char *hint,
> }
> else
> {
> - struct value *value = convert_value_from_python (py_v);
> + struct value *value;
>
> - if (value == NULL)
> + if (try_convert_value_from_python (py_v, &value))
> + {
> + if (value == NULL)
> + {
> + gdbpy_print_stack ();
> + error (_("Error while executing Python code."));
> + }
I'm not sure what his change gives us? You still raise an exception,
if value = NULL? Which is what the old code did.
> + else
> + common_val_print (value, stream, recurse + 1, options,
> + language);
> + }
> + else if (PyObject_HasAttr (py_v, gdbpy_to_string_cst))
> + {
> + /* have another pretty printer to run */
> + run_pretty_printer (py_v, stream, recurse + 1, options, language,
> + gdbarch);
> + }
So, in this case, if try_convert_value_to_python returns false, one
assumes there is a nested printer? Can printers nest other printer
ad infinitum? What happens if the nested printer returns another nested
printer? It's not clear here what the implications are.
> /* Try to convert a Python value to a gdb value. If the value cannot
> - be converted, set a Python exception and return NULL. Returns a
> - reference to a new value on the all_values chain. */
> -
> -struct value *
> -convert_value_from_python (PyObject *obj)
> + be converted because it was of the incorrect type return 0. If the value
> + was of the correct type set value to a reference to a new value on the
> + all_values chain and returns 1. If a Python exception occurs attempting to
> + convert the value then value is set to NULL and 1 is returned */
> +int
> +try_convert_value_from_python (PyObject *obj, struct value **value)
> {
> - struct value *value = NULL; /* -Wall */
> + int typeok = 1;
As I noted, I really don't like this change. I think you should create
a new function that wraps this one and discards the exception rather
than altering this. Essentially the opposite of what you have done.
> +/* Try to convert a Python value to a gdb value. If the value cannot
> + be converted, set a Python exception and return NULL. Returns a
> + reference to a new value on the all_values chain. */
> +struct value *
> +convert_value_from_python (PyObject *obj)
> +{
> + struct value * value;
> + if (!try_convert_value_from_python(obj, &value))
> + PyErr_Format (PyExc_TypeError,
> + _("Could not convert Python object: %s."),
> + PyString_AsString (PyObject_Str (obj)));
> return value;
So this would be try_convert_value_from_python that just discarded the
exception. But there are deeper problems. In this case, if there
really is an error converting a value, in your code you replace it with
a generic exception. I think the old code is wrong in this too. I
think if there is an exception, we should not mask it. I guess we could
mask particular types given your case.
Cheers,
Phil
next prev parent reply other threads:[~2011-08-17 9:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-14 16:11 Python API - nested pretty printers MI implications Andrew Oakley
2011-08-14 22:18 ` Daniel Jacobowitz
2011-08-15 12:36 ` André Pönitz
2011-08-15 13:26 ` Pedro Alves
2011-08-15 14:33 ` André Pönitz
2011-08-15 14:49 ` Pedro Alves
2011-08-15 15:36 ` André Pönitz
2011-08-16 22:12 ` Andrew Oakley
2011-08-16 22:23 ` [PATCH] Allow nested python pretty printers andrew
2011-08-17 9:56 ` Phil Muldoon [this message]
2011-08-17 13:28 ` Andrew Oakley
2011-08-15 12:58 ` Python API - nested pretty printers MI implications Pedro Alves
2011-08-15 14:06 ` Andrew Oakley
2011-08-15 14:30 ` Pedro Alves
2011-08-16 22:12 ` Andrew Oakley
2011-08-17 12:49 ` Pedro Alves
2011-08-17 18:31 ` Andrew Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ippw2wfr.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=andrew@ado.is-a-geek.net \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox