From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [python] [patch] PR python/13329
Date: Tue, 29 Nov 2011 13:57:00 -0000 [thread overview]
Message-ID: <m37h2jxc93.fsf@redhat.com> (raw)
In-Reply-To: <m3r516eah3.fsf@fleche.redhat.com> (Tom Tromey's message of "Thu, 17 Nov 2011 13:54:16 -0700")
Tom Tromey <tromey@redhat.com> writes:
> Phil> +/* 0 if we should not print the stack when catching a Python error,
> Phil> + 1 to print the full stack, 2 to just print the message. */
> Phil> +static int gdbpy_should_print_stack = 2;
>
> It is more normal, though not exclusively the case (I think), to just
> use the string constants here. Because they are constant strings you
> can just compare them with ==.
>
> That is, you can just remove this variable.
>
> Phil> +/* The extended exception printing variable. 'full' if we want to
> Phil> + print the error message and stack, 'none' if we want to print
> Phil> + nothing, and 'message' if we only want to print the error
> Phil> + message. */
> Phil> +static const char *gdbpy_should_print_stack_extended =
> Phil> + python_excp_message;
>
> ... and rename this to gdbpy_should_print_stack and use it directly.
>
> Phil> +/* When setting the 'python print-stack' with an enum, set the
> Phil> + gdbpy_should_print_stack correspondingly. */
> Phil> +static void
> Phil> +set_python_excp_mode (char *args, int i, struct cmd_list_element *c)
I have to keep/add these functions around to be compatible with "maint
set python print-stack" which is a boolean parameter. So it was my view
we still operate on the gdbpy_should_print_stack variable in
gdbpy_print_stack function, and have the "set function" just set
gdbpy_should_print_stack from the enum command. I can do what you wish,
but I would have to write a "set" function to set the enum constant
instead.
> With the above change you won't need this function.
>
> Phil> + add_setshow_enum_cmd ("print-stack", no_class, python_excp_enums,
> Phil> + &gdbpy_should_print_stack_extended, _("\
> Phil> +Set mode for Python stack dump on error."), _("\
> Phil> +Show the mode of Python stack printing on error."), _("\
> Phil> +none == no stack or message will be printed.\n\
> Phil> +full == a message and a stack will be printed.\n\
> Phil> +message == an error message without a stack will be printed."),
> Phil> + set_python_excp_mode, NULL,
> Phil> + &user_set_python_list,
> Phil> + &user_show_python_list);
>
> I'm surprised this is backward compatible.
The user command "set python print-stack" has not been published in a
release so it is not compatible; I believe it is within our API pledge
to change whatever we like until that feature is released. "maint set
python print-stack" still works, but is deprecated. For the variable
gdbpy_should_print_stack, 0 is still off, 1 is full, 2 is message only.
The "maint set python print-stack" will only ever set off or full.
> Phil> -gdb_test_no_output "set python print-stack on"
> Phil> +gdb_test_no_output "set python print-stack full"
>
> You should leave in some compatibility tests for the old values.
Do you mean use "maint set python print-stack" here?
> I didn't look but you should try the old code to see exactly what values
> it accepted. I thought the boolean set/shows took more than just on/off.
I will, but the result remains the same. 0 for off, > 0 for on.
Cheers
Phil
next prev parent reply other threads:[~2011-11-29 13:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 15:36 Phil Muldoon
2011-11-09 15:49 ` Kevin Pouget
2011-11-09 20:25 ` Phil Muldoon
2011-11-17 20:55 ` Tom Tromey
2011-11-29 13:57 ` Phil Muldoon [this message]
2011-12-08 13:08 ` Phil Muldoon
2011-12-13 19:40 ` Tom Tromey
2011-12-15 18:15 ` Phil Muldoon
2011-12-15 21:27 ` Eli Zaretskii
2011-12-16 0:51 ` Tom Tromey
2011-12-16 15:15 ` Phil Muldoon
2011-12-16 15:17 ` Tom Tromey
2011-12-16 17:16 ` Phil Muldoon
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=m37h2jxc93.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/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