Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
	Fernando Nasser <fnasser@cygnus.com>,
	gdb-patches@sources.redhat.com, Don Howard <dhoward@redhat.com>,
	Michael Snyder <msnyder@cygnus.com>
Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
Date: Wed, 26 Sep 2001 14:57:00 -0000	[thread overview]
Message-ID: <3BB24E4A.D31D4196@redhat.com> (raw)
In-Reply-To: <1010926211948.ZM2311@ocotillo.lan>

Kevin Buettner wrote:
> 
> On Sep 26,  4:01pm, Fernando Nasser wrote:
> 
> > And I don't think Don's latest patch is complex, or considerably more
> > complex than the simplistic copy approach (or hack!).  It is elegant
> > (although Kevin's comments are valid and should be incorporated).
> >
> > If Don can add a cleanup function and do the polishing suggested by Kevin
> > on his last patch I suggest that we stick with that one.
> 
> Here are my preferences...
> 
> I like the patch that makes a copy the best since the changes are easy
> to understand and localized to one function.
> 
> Next best would be a patch (unwritten as of now) which implements
> reference counts for these command chains.  I think that a lot of
> folks understand reference counts and it takes less time to grok code
> written with this design pattern.  In all likelyhood, such a patch
> would look somewhat similar to Don's latest patch though; i.e, the
> changes would be distributed among several files and would likely be
> in the same functions that Don has touched with his latest patch.
> 
> Next best would be Don's latest patch revised to use an enum for
> the ``execute'' member.  I think this code would be easier to
> understand by giving the 0, 1, and 2+ values actual names that are
> meaningful.  I still have concerns about what might happen if
> bpstat_do_actions() is ever executed recursively...  I don't think this
> ever happens, so it's probably a non-issue, but if it could happen,
> then a reference counting mechanism would definitely be superior.
> 
> (All of the above approaches need to make use of a cleanup.)
> 
> Kevin
> 

That is a good analysis.  My preference is know to be the second above.
However, if a _real_ consensus is reached on the external list that we
should just use the duplicating patch I will remove my objections.


> P.S. I'd like to publicly thank Don for all the hard work he has
> put in on this patch.  I imagine it must be frustrating to be told
> to do the patch one way by one person, a different way by a second,
> and still a different way by a third...

I would like to second that.  It must be noted that Don has not, in 
any moment, has complained of anything.  On the contrary, he kept
thinking about the problem and trying to provide alternative 
solutions.  In the best tradition of the best Open Source contributors.

W.r.t. the pain of having to re-work patches comes with the job.  That
people will have different views and preferences comes with humanity.
This happens in any Open Source project -- we have been through this 
before in this list and the same thing happens daily on the PostgreSQL
database project lists.  We could have discussed alternatives without
Don writing patches, but it was his patches that kept bringing more
light into the problem (fr himself included).   And he learned that
globals are no-no's among other things, was able to understand some
more parts of the code etc.  It was not wasted time.

P.S.: I would like to see some people going through a Ph.D. and having
to change things in circle until your supervisor understands you. 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


  reply	other threads:[~2001-09-26 14:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0109211638230.1755-100000@theotherone>
2001-09-24 17:10 ` Kevin Buettner
2001-09-24 17:33   ` Kevin Buettner
2001-09-24 18:52   ` Andrew Cagney
2001-09-26 13:07     ` Fernando Nasser
2001-09-26 14:20       ` Kevin Buettner
2001-09-26 14:57         ` Fernando Nasser [this message]
2001-09-26 15:09           ` Andrew Cagney
2001-09-17  9:34 Don Howard
2001-09-17 15:39 ` Michael Snyder
2001-09-18  6:56   ` Fernando Nasser
2001-09-18  7:56     ` Andrew Cagney
2001-09-18  8:09       ` Fernando Nasser
2001-09-18 10:34       ` Michael Snyder
2001-09-18 17:47         ` Andrew Cagney
2001-09-18 18:03           ` Michael Snyder
2001-09-19  7:20             ` Fernando Nasser
2001-09-19  8:17               ` Andrew Cagney
2001-09-19  9:22                 ` Fernando Nasser
2001-09-19  9:33                 ` Don Howard
2001-09-19 12:08                   ` Kevin Buettner
2001-09-19 12:18                     ` Michael Snyder
2001-09-19 13:09                       ` Kevin Buettner
     [not found]                     ` <3BA905AD.5F8F1A68@redhat.com>
2001-09-19 14:22                       ` Kevin Buettner
2001-09-19 14:44                         ` Fernando Nasser
2001-09-20 15:24                 ` Don Howard
2001-09-20 18:05                   ` Andrew Cagney

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=3BB24E4A.D31D4196@redhat.com \
    --to=fnasser@redhat.com \
    --cc=ac131313@cygnus.com \
    --cc=dhoward@redhat.com \
    --cc=fnasser@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.com \
    --cc=msnyder@cygnus.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