Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Bob Rossi <bob_rossi@cox.net>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Alain Magloire <alain@qnx.com>, gdb@sources.redhat.com
Subject: Re: asynchronous MI output commands
Date: Thu, 11 May 2006 14:50:00 -0000	[thread overview]
Message-ID: <20060511123440.GI3727@brasko.net> (raw)
In-Reply-To: <200605111523.24678.ghost@cs.msu.su>

On Thu, May 11, 2006 at 03:23:22PM +0400, Vladimir Prus wrote:
> On Thursday 11 May 2006 14:55, Bob Rossi wrote:
> 
> > > > >     const GDBMI::Value& children = r["children"];
> > > > >
> > > > >     for (unsigned i = 0; i < children.size(); ++i)
> > > > >     {
> > > > >         QString exp = children[i]["exp"].literal();
> > > > >
> > > > >
> > > > > If you have specific structures for each response this won't be very
> > > > > much simpler.
> > > >
> > > > Sorry, I've described this before, but apparently not good enough. I
> > > > definatly can create the abstract parse tree with out knowing the input
> > > > command. However, then I want to create C data structures for each
> > > > MI output.
> > >
> > > Why? With C data structures, the above frontend code will be only
> > > marginally simpler.
> >
> > I don't believe that to be the case at all. Look at the C data structure
> > code I have for the -break-list data structure. If a GUI had to use this I
> > think they would be happy.
> 
> So, instead of say:
> 
>     bp["number"].toInt()
> 
> I'd write:
> 
>     bp.number
> 
> ? Well, that's what I call "marginally better". It's better, but not likely to 
> make big practical difference.
> 
> Also, you propose C interface, so is not directly usable in frontend written 
> in C++. Such frontend will likely to have it's own class for breakpoint, and 
> would have to convert from your structure to that class.

Yeah, this will have to happen regardless. I mean, if I only have the
parse tree, it will need to be ported to other languages also. For C++,
it's particular easy, you can either inherit from the struct or use
composition.

> I guess if you want to make MI parser for your own use, any approach is fine. 
> But if you want to make some kind of "standard" MI parser for other frontends 
> to use, I'm not sure that providing such pre-made structures will be a 
> selling point.

Well, I suppose I'll provide them for myself, and others can easily use
the parse tree if that's what they want to do. However, I must warn you,
using the parse tree is more complicated than what you have above. I'm
not exactly sure how you can simply say 
  bp["number"].toInt ()
where does "bp" come from? Is it a pointer into the parse tree? If so,
how did you get to that point?

I have to get the parse tree, which is stored in 'output_ptr' below.
Then i have to get all the way to the result_ptr which has "number" as
the variable. I see you are using a map in C++ which makes the code much
cleaner. I don't have that advantage in C.
  
    gdbmi_result_ptr result_ptr = output_ptr->result_record->result;
    if (strcmp (result_ptr->variable, "BreakpointTable") == 0)
    {
      if (result_ptr->value->value_choice == GDBMI_TUPLE)
      {
	result_ptr = result_ptr->value->option.tuple->result;
	while (result_ptr)
	{
	  if (strcmp (result_ptr->variable, "body") == 0)
	  {
	    if (result_ptr->value->value_choice == GDBMI_LIST)
	    {
	      gdbmi_list_ptr list_ptr = result_ptr->value->option.list;
	      if (list_ptr && list_ptr->list_choice == GDBMI_RESULT)
	      {
		gdbmi_result_ptr result_ptr = list_ptr->option.result;
		while (result_ptr)
		{
		  if (strcmp (result_ptr->variable, "bkpt") == 0)
		  {
		    gdbmi_oc_breakpoint_ptr ptr = create_gdbmi_breakpoint ();

		    gdbmi_value_ptr value_ptr = result_ptr->value;
		    if (value_ptr->value_choice == GDBMI_TUPLE)
		    {
		      gdbmi_result_ptr result_ptr = value_ptr->option.tuple->result;
		      while (result_ptr)
		      {
			if (strcmp (result_ptr->variable, "number") == 0)
			{
			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
			  {
			    char *nstr;
			    if (convert_cstring (result_ptr->value->option.cstring, &nstr) == -1)
			    {
			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
			      return -1;
			    }

			    ptr->number = atoi (nstr);
			    free (nstr);
			    nstr = NULL;
			  }
			} 
			result_ptr = result_ptr->next;
		      }
		    }

		    oc_ptr->input_commands.break_list.breakpoint_ptr =
		       append_gdbmi_breakpoint (oc_ptr->input_commands.break_list.breakpoint_ptr, ptr);
		  }
		  result_ptr = result_ptr->next;
		}
	      }
	    }
	  }
	  result_ptr = result_ptr->next;
	}
      }
    }

> > I do 
> > know that I have some code duplicated that could be in a function, and
> > some other cleanups, but I still think it's far more difficult.
> 
> I think the code you've presented indeed has too much copy-paste. For example:
> 
>  			else if (strcmp (result_ptr->variable, "addr") == 0)
>  			{
>  			  if (result_ptr->value->value_choice == GDBMI_CSTRING)
>  			  {
>  			    if (convert_cstring (result_ptr->value->option.cstring,
>                       &ptr->address) == -1) 
>                   {
>  			      fprintf (stderr, "%s:%d\n", __FILE__, __LINE__);
>  			      return -1;
>  			    }
>  			  }
>  			}
> 
> is a pattern that repeats for many of fields. While in my interface, you'd 
> call:
> 
>    bp["addr"].literal()
> 
> to get exactly same effect. Except that in your code, no error is emitted when 
> "addr" field is not of string type ;-)

I intentionally left out the error. I'm not sure how much error code I
should have in this library if it needs to work in all circumstances.
I'm still thinking about that.

> Maybe if you provide functions  'get_literal' and 'get_integer' and 
> 'get_bool_yn', the size of code can be reduced considerably.

Thanks for the suggestion, I'll try that.

Bob Rossi


  reply	other threads:[~2006-05-11 14:14 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-10 22:15 Alain Magloire
2006-05-11  3:41 ` Bob Rossi
2006-05-11  8:58   ` Vladimir Prus
2006-05-11 10:48     ` Bob Rossi
2006-05-11 10:52       ` Vladimir Prus
2006-05-11 11:14         ` Bob Rossi
2006-05-11 12:50           ` Vladimir Prus
2006-05-11 14:50             ` Bob Rossi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-12  0:19 Alain Magloire
2006-05-11 15:02 Alain Magloire
2006-05-11 15:42 ` Bob Rossi
2006-05-11 16:40   ` Jim Ingham
2006-05-11 17:03     ` Daniel Jacobowitz
2006-05-11 17:35       ` Jim Ingham
2006-05-11 19:24     ` Bob Rossi
2006-05-11 19:25       ` Jim Ingham
2006-05-09  9:46 Alain Magloire
2006-05-07 22:30 Bjarke Viksoe
2006-05-07 22:50 ` Daniel Jacobowitz
2006-05-08  0:36   ` Bjarke Viksoe
2006-05-08  1:52     ` Daniel Jacobowitz
     [not found] <1147034156.28828.ezmlm@sourceware.org>
2006-05-07 21:27 ` Bjarke Viksoe
2006-05-07 21:41   ` Daniel Jacobowitz
2006-05-10 12:43     ` Vladimir Prus
2006-05-06  1:26 Bob Rossi
2006-05-06  1:59 ` Daniel Jacobowitz
2006-05-06  2:48   ` Bob Rossi
2006-05-06  3:37     ` Nick Roberts
2006-05-06 15:20       ` Bob Rossi
2006-05-06  4:06     ` Daniel Jacobowitz
2006-05-06  4:05       ` Daniel Jacobowitz
2006-05-06 11:53       ` Bob Rossi
2006-05-06 12:06         ` Bob Rossi
2006-05-06  3:14   ` Bob Rossi
2006-05-06  4:04     ` Nick Roberts
2006-05-06 11:49       ` Daniel Jacobowitz
2006-05-06 11:50         ` Bob Rossi
2006-05-06 16:52           ` Daniel Jacobowitz
2006-05-06 19:45             ` Bob Rossi
2006-05-06 20:37               ` Daniel Jacobowitz
2006-05-07  0:44                 ` Bob Rossi
2006-05-07 20:35                   ` Daniel Jacobowitz
2006-05-07 20:42                     ` Bob Rossi
2006-05-07 22:01                       ` Daniel Jacobowitz
2006-05-08  1:22                         ` Bob Rossi
2006-05-08  2:03                           ` Daniel Jacobowitz
2006-05-09 21:48                             ` Bob Rossi
2006-05-08  6:38                           ` Nick Roberts
2006-05-08 11:28                             ` Bob Rossi
2006-05-08  1:26                         ` Bob Rossi
2006-05-06 11:51       ` Bob Rossi
2006-05-06  3:27 ` Nick Roberts
2006-05-06 16:40   ` Bob Rossi

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=20060511123440.GI3727@brasko.net \
    --to=bob_rossi@cox.net \
    --cc=alain@qnx.com \
    --cc=gdb@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /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