-break-delete with several breakpoints

I've noticed that right now, both -break-delete and
-break-disable
commands accept several breakpoint ids, like:

	-break-disable 1 2 3

This behaviour comes almost by accident, and is not
documented anywhere.
The question is -- should we document it and add tests, or
should we
declare this behaviour does not exist?

I think that most of the time, making use of this behaviour
will require
explicit code in the frontend, and the question is if that
makes sense.
Say, for -var-update accepting a list of variable object
might be good idea,
since the number of variable object can be significant, and
they are updated
on each step. For deleting and disabling breakpoints, I'm
actually not sure.
Typically, there are few breakpoints and wholesale delete is
not common,
so it's not worth optimizing for.

Opinions?

- Volodya

On Sat, Apr 26, 2008 at 10:08:50PM +0400, Vladimir Prus
wrote:
> 
> I've noticed that right now, both -break-delete and
-break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not
documented anywhere.
> The question is -- should we document it and add tests,
or should we
> declare this behaviour does not exist?
> 
> I think that most of the time, making use of this
behaviour will require
> explicit code in the frontend, and the question is if
that makes sense.
> Say, for -var-update accepting a list of variable
object might be good idea,
> since the number of variable object can be significant,
and they are updated
> on each step. For deleting and disabling breakpoints,
I'm actually not sure.
> Typically, there are few breakpoints and wholesale
delete is not common,
> so it's not worth optimizing for.
> 
> Opinions?

The only case I can think that would be nice is something
like,
  -break-disable -all

Bob Rossi

 > > Opinions?
 > 
 > The only case I can think that would be nice is
something like,
 >   -break-disable -all

-break-disable with no argument will already do this as it
just executes
the CLI command "disable".

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Sunday 27 April 2008 02:19:00 Nick Roberts wrote:
>  > > Opinions?
>  > 
>  > The only case I can think that would be nice is
something like,
>  >   -break-disable -all
> 
> -break-disable with no argument will already do this as
it just executes
> the CLI command "disable".

Which is not guaranteed to be the case in future. That's why
I'm trying to
figure what is desired behaviour is.

- Volodya

 > >  > The only case I can think that would be
nice is something like,
 > >  >   -break-disable -all
 > > 
 > > -break-disable with no argument will already do
this as it just executes
 > > the CLI command "disable".
 > 
 > Which is not guaranteed to be the case in future.
That's why I'm trying to
 > figure what is desired behaviour is.

Leave it as it is?  It doesn't really bother me as these
commands don't
create any output and Emacs needs to work with the CLI
commands in the GUD
buffer anyway.  

I think more important than the input syntax is some kind of
output as I
suggested in:

http://sourceware.org/ml/gdb-patches/2008-04/msg00377.
html

And it should work with CLI  commands too, i.e., through
event notification.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

 > >  > The only case I can think that would be
nice is something like,
 > >  >   -break-disable -all
 > > 
 > > -break-disable with no argument will already do
this as it just executes
 > > the CLI command "disable".
 > 
 > Which is not guaranteed to be the case in future.
That's why I'm trying to
 > figure what is desired behaviour is.

Leave it as it is?  It doesn't really bother me as these
commands don't
create any output and Emacs needs to work with the CLI
commands in the GUD
buffer anyway.  

I think more important than the input syntax is some kind of
output as I
suggested in:

http://sourceware.org/ml/gdb-patches/2008-04/msg00377.
html

And it should work with CLI  commands too, i.e., through
event notification.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Saturday 26 April 2008 20:08:50 Vladimir Prus wrote:
> 
> I've noticed that right now, both -break-delete and
-break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not
documented anywhere.
> The question is -- should we document it and add tests,
or should we
> declare this behaviour does not exist?

I would disallow it. Keep it simple 

> I think that most of the time, making use of this
behaviour will require
> explicit code in the frontend, and the question is if
that makes sense.

I doubt it would. I could as well fire off three separate
commands.
As that would not require extra roundtrips, that's basically
'free'. 

> Say, for -var-update accepting a list of variable
object might be good idea,
> since the number of variable object can be significant,
and they are updated
> on each step. For deleting and disabling breakpoints,
I'm actually not sure.
> Typically, there are few breakpoints and wholesale
delete is not common,
> so it's not worth optimizing for.

I fully agree.

Andre'

On Sat, 2008-04-26 at 22:08 +0400, Vladimir Prus wrote:
> I've noticed that right now, both -break-delete and
-break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not
documented anywhere.
> The question is -- should we document it and add tests,
or should we
> declare this behaviour does not exist?
> 
> I think that most of the time, making use of this
behaviour will require
> explicit code in the frontend, and the question is if
that makes sense.
> Say, for -var-update accepting a list of variable
object might be good idea,
> since the number of variable object can be significant,
and they are updated
> on each step. For deleting and disabling breakpoints,
I'm actually not sure.
> Typically, there are few breakpoints and wholesale
delete is not common,
> so it's not worth optimizing for.
> 
> Opinions?

I'm guessing that this is an artifact of the fact that 
the CLI commands (break, delete, enable, disable...)
are all willing to accept this type of argument list.