Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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