MI: output of -break-insert and -break-watch

MI: output of -break-insert and -break-watch

[Vladimir Prus]

Hello!

The output of -break-insert and -break-watch currently looks like this:

  ^done,bkpt={number="1",......

and
  
  ^done,wpt={number="2",.......

What is exactly the point of using different field names: "bkpt" and "wpt"?
This makes it impossible to get the number of set breakpoint in a uniform
fashion -- I need to have some conditional on the type of breakpoint, or
add logic that checks if "bkpt" or "wpt" is present in reply.

Why can't we have just:

  ^done,number="1"

? And this can be done in backward-compatible way, btw.


- Volodya

Re: MI: output of -break-insert and -break-watch

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 17 Feb 2006 15:37:21 +0300
> 
> The output of -break-insert and -break-watch currently looks like this:
> 
>   ^done,bkpt={number="1",......
> 
> and
>   
>   ^done,wpt={number="2",.......
> 
> What is exactly the point of using different field names: "bkpt" and "wpt"?
> This makes it impossible to get the number of set breakpoint in a uniform
> fashion -- I need to have some conditional on the type of breakpoint, or
> add logic that checks if "bkpt" or "wpt" is present in reply.
> 
> Why can't we have just:
> 
>   ^done,number="1"
> 
> ? And this can be done in backward-compatible way, btw.

How about

   ^done,type="wpt",number="2"...

or
   ^done,bkpt={number="2",type="wpt",...

instead?

I think leaving the breakpoint type out might not be a good idea,
since the response might not come in sync with the commands.  That is,
you could have sent several commands before you get the first
response.  In that case, you will not easily know which response is
for what command.

Re: MI: output of -break-insert and -break-watch

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:37:21PM +0300, Vladimir Prus wrote:
> 
> Hello!
> 
> The output of -break-insert and -break-watch currently looks like this:
> 
>   ^done,bkpt={number="1",......
> 
> and
>   
>   ^done,wpt={number="2",.......
> 
> What is exactly the point of using different field names: "bkpt" and "wpt"?
> This makes it impossible to get the number of set breakpoint in a uniform
> fashion -- I need to have some conditional on the type of breakpoint, or
> add logic that checks if "bkpt" or "wpt" is present in reply.

I don't get it.  Why is this a problem?  It sounds to me like the only
reason this would be awkward would be limitations of your front end.
If you've done -break-insert you should expect a bkpt response, if
you've done -break-watch you should expect a wpt response.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: output of -break-insert and -break-watch

[Vladimir Prus]

On Friday 17 February 2006 16:53, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 17 Feb 2006 15:37:21 +0300
> >
> > The output of -break-insert and -break-watch currently looks like this:
> >
> >   ^done,bkpt={number="1",......
> >
> > and
> >
> >   ^done,wpt={number="2",.......
> >
> > What is exactly the point of using different field names: "bkpt" and
> > "wpt"? This makes it impossible to get the number of set breakpoint in a
> > uniform fashion -- I need to have some conditional on the type of
> > breakpoint, or add logic that checks if "bkpt" or "wpt" is present in
> > reply.
> >
> > Why can't we have just:
> >
> >   ^done,number="1"
> >
> > ? And this can be done in backward-compatible way, btw.
>
> How about
>
>    ^done,type="wpt",number="2"...
>
> or
>    ^done,bkpt={number="2",type="wpt",...
>
> instead?

That is, with added "type" field? No objections from me.

> I think leaving the breakpoint type out might not be a good idea,
> since the response might not come in sync with the commands.  That is,
> you could have sent several commands before you get the first
> response.  In that case, you will not easily know which response is
> for what command.

I'm not sure about this. If your really want to send several command, there 
are two mechanisms:

1. You can use the "token" in original MI command, which will be returne in 
reply.

2. You can just send the commands anyway, and keep a list of commands for 
which there's no reply. I believe that the order of replies and commands is 
the same, so it's easy to match replies with commands.

Anyway, extra "type" field won't hurt much.


- Volodya

Re: MI: output of -break-insert and -break-watch

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Feb 17, 2006 at 03:37:21PM +0300, Vladimir Prus wrote:
>> 
>> Hello!
>> 
>> The output of -break-insert and -break-watch currently looks like this:
>> 
>>   ^done,bkpt={number="1",......
>> 
>> and
>>   
>>   ^done,wpt={number="2",.......
>> 
>> What is exactly the point of using different field names: "bkpt" and
>> "wpt"? This makes it impossible to get the number of set breakpoint in a
>> uniform fashion -- I need to have some conditional on the type of
>> breakpoint, or add logic that checks if "bkpt" or "wpt" is present in
>> reply.
> 
> I don't get it.  Why is this a problem?  It sounds to me like the only
> reason this would be awkward would be limitations of your front end.
> If you've done -break-insert you should expect a bkpt response, if
> you've done -break-watch you should expect a wpt response.

Here's the code I use now to extract breakpoint id from response:

            int id = -1;

            if (r.hasField("bkpt"))
                id = r["bkpt"]["number"].literal().toInt();
            else if (r.hasField("wpt"))
                id = r["wpt"]["number"].literal().toInt();
            else if (r.hasField("hw-rwpt"))
                id = r["hw-rwpt"]["number"].literal().toInt();

And there's also "hw-awpt", and in future there might be "catchpoint" and
"fork" and what not. 

If I only want to extract the *id* of breakpoint, why do I need to write
such boilerplate? Or should I write a function that will iterate over all
fields of 'r', and check if that field has nested field called 'number'?

- Volodya

Re: MI: output of -break-insert and -break-watch

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 05:13:52PM +0300, Vladimir Prus wrote:
> > I don't get it.  Why is this a problem?  It sounds to me like the only
> > reason this would be awkward would be limitations of your front end.
> > If you've done -break-insert you should expect a bkpt response, if
> > you've done -break-watch you should expect a wpt response.
> 
> Here's the code I use now to extract breakpoint id from response:
> 
>             int id = -1;
> 
>             if (r.hasField("bkpt"))
>                 id = r["bkpt"]["number"].literal().toInt();
>             else if (r.hasField("wpt"))
>                 id = r["wpt"]["number"].literal().toInt();
>             else if (r.hasField("hw-rwpt"))
>                 id = r["hw-rwpt"]["number"].literal().toInt();
> 
> And there's also "hw-awpt", and in future there might be "catchpoint" and
> "fork" and what not. 
> 
> If I only want to extract the *id* of breakpoint, why do I need to write
> such boilerplate? Or should I write a function that will iterate over all
> fields of 'r', and check if that field has nested field called 'number'?

This still sounds to me like it has more to do with the architecture of
your front-end than it does with meaningful layout of MI.  This is only
about the response to -break-insert and -break-watch as far as I
understand.  So if you want to avoid the conditional, you can record
which type to expect when you issue the command.  Or leave the
conditional; it's not that bad, is it?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: output of -break-insert and -break-watch

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 05:13:52PM +0300, Vladimir Prus wrote:
> > I don't get it.  Why is this a problem?  It sounds to me like the only
> > reason this would be awkward would be limitations of your front end.
> > If you've done -break-insert you should expect a bkpt response, if
> > you've done -break-watch you should expect a wpt response.
> 
> Here's the code I use now to extract breakpoint id from response:
> 
>             int id = -1;
> 
>             if (r.hasField("bkpt"))
>                 id = r["bkpt"]["number"].literal().toInt();
>             else if (r.hasField("wpt"))
>                 id = r["wpt"]["number"].literal().toInt();
>             else if (r.hasField("hw-rwpt"))
>                 id = r["hw-rwpt"]["number"].literal().toInt();
> 
> And there's also "hw-awpt", and in future there might be "catchpoint" and
> "fork" and what not. 
> 
> If I only want to extract the *id* of breakpoint, why do I need to write
> such boilerplate? Or should I write a function that will iterate over all
> fields of 'r', and check if that field has nested field called 'number'?

This still sounds to me like it has more to do with the architecture of
your front-end than it does with meaningful layout of MI.  This is only
about the response to -break-insert and -break-watch as far as I
understand.  So if you want to avoid the conditional, you can record
which type to expect when you issue the command.  Or leave the
conditional; it's not that bad, is it?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: output of -break-insert and -break-watch

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Feb 17, 2006 at 05:13:52PM +0300, Vladimir Prus wrote:
>> > I don't get it.  Why is this a problem?  It sounds to me like the only
>> > reason this would be awkward would be limitations of your front end.
>> > If you've done -break-insert you should expect a bkpt response, if
>> > you've done -break-watch you should expect a wpt response.
>> 
>> Here's the code I use now to extract breakpoint id from response:
>> 
>>             int id = -1;
>> 
>>             if (r.hasField("bkpt"))
>>                 id = r["bkpt"]["number"].literal().toInt();
>>             else if (r.hasField("wpt"))
>>                 id = r["wpt"]["number"].literal().toInt();
>>             else if (r.hasField("hw-rwpt"))
>>                 id = r["hw-rwpt"]["number"].literal().toInt();
>> 
>> And there's also "hw-awpt", and in future there might be "catchpoint" and
>> "fork" and what not.
>> 
>> If I only want to extract the *id* of breakpoint, why do I need to write
>> such boilerplate? Or should I write a function that will iterate over all
>> fields of 'r', and check if that field has nested field called 'number'?
> 
> This still sounds to me like it has more to do with the architecture of
> your front-end than it does with meaningful layout of MI.  

Well, I'm not sure it's specific to KDevelop:

1. All frontends will want to know the id of the set breakpoint, as that's
the only information that allows to modify the breakpoint later.

2. The above "bkpt" and so on are MI-specific names which must be hardcoded
in frontend somewhere.

> This is only 
> about the response to -break-insert and -break-watch as far as I
> understand.  So if you want to avoid the conditional, you can record
> which type to expect when you issue the command.  

And if I have to remember the type of breakpoint command I've sent, then
what's the use of the different naming of field in reply -- it clearly not
need to recover the type of breakpoint, as I've already remembered it.

> Or leave the conditional; it's not that bad, is it?

Well, it just got another "if" clause for "hw-awpt", and I'd expect this to
grow by a couple over time. No, it's no a big architectural thing, but
still an annoyance.

- Volodya