Re: [PATCH] Add support for embedding scripts in .debug_gdb_scripts.

[Doug Evans <xdje42 at gmail dot com>]

On Sat, Jan 17, 2015 at 12:17 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 16 Jan 2015 17:15:49 -0800
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> On Fri, Jan 16, 2015 at 10:01 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > So we have no hope for ever fixing past mistakes?
>>
>> Past mistakes?
>> .debug_gdb_scripts isn't that old of a feature.
>
> I wasn't talking only about that.  I was talking in general about the
> argument "we do this elsewhere 'like this', so let's continue doing
> that 'like this'".  For example, the "NUL" thingie.

NUL has been the name of the zero byte in ASCII since the early 60s.
It's hardly a "thingie".

http://en.wikipedia.org/wiki/ASCII

>
>> Maybe we need more formal community-agreed-on
>> conventions and rules for NEWS and docs.
>
> Maybe we should, but I'd like first to agree that an argument of this
> kind doesn't have too much weight.  It's okay to look at past
> practices when the choice is purely stylistic.  But when there are
> clear advantages to deviating from past practices, those past
> practices shouldn't hold us back, otherwise we will stagnate.  Agreed?

Only to the extent that such reasoning must be re-evaluated
every time it is applied.

Plus, I don't understand the point about more formal conventions
not having too much weight.  People should be able to write code
with some expectation that what they've written is correct.
The same should be true with NEWS/doc.
And one way we do that is with documented rules and conventions.

If we're going to have such stringent rules in gdb for NEWS/docs,
then I think at least things that have been non-obvious in the past
should be written down.

> In this case, "NUL" is simply incorrect English: there's no such word
> or acronym.  The only legitimate use of "NUL" I know of is in
> reference to the DOS/Windows null device.

Au contraire.
NUL has been the common name of the zero byte since long before
gdb was born.
Ref: above link on ASCII, for example

> As for showing the systems where .debug_gdb_scripts feature is
> supported, there are clear advantages to providing that information in
> NEWS, and the price is quite low, I hope you will agree.

It is documented in gdb.texinfo.
I don't see the point of repeating it in NEWS,
especially for a case such as this.
[I just don't see its presence in this particular
case making a material difference in anyone's life.]

https://sourceware.org/gdb/current/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html#dotdebug_005fgdb_005fscripts-section

Tell ya what though.
Let's add a new section to the conventions wiki for NEWS/docs.
One of those entries will be:

All NEWS entries for new features shall specify the platform(s) on which
the feature is available, if it is not a generally available feature.
[or words to that effect]
And let's enforce all these rules the way we do
coding conventions (which I don't have a problem with).

Ok?

That way everyone can be on the same page,
and there is a document one can refer people to.

> I can also live with you asking me in response to please change all
> the other instances to use the same style.  But what I would prefer
> not to live with is flat refusal to make a requested change in your
> patch because "we do that elsewhere".

If I believe the request is invalid (e.g., NUL), then
I've got to push back.  In the NUL case,
this term is so common that to outlaw it in
gdb docs would be a real shame.
I wasn't aware, until now, that you weren't aware of
how common NUL is.  Otherwise I would have
pointed it out sooner. Sorry!

Also, until the patch is checked in, it's premature
to assess whether anything was flatly refused.

I proposed writing down rules NEWS/doc entries are expected to follow.
Ideally there won't be many, but certainly non-obvious ones
should be, and as for who decides what's non-obvious:
anytime discussions like these comes up works for me.

If the community agrees to requiring new non-general features
in NEWS to always specify the platform they're for, then I'm happy
to go with the flow.

>> These things seem to be of a "shall be this way" flavor,
>> and I wasn't expecting that.
>
> Isn't that normal during patch review process?

Not when one of the choices is perfectly valid (e.g., NUL).

>> When I cut-n-paste from code I can usually
>> tell what's expected, but I can't do that for NEWS/doc,
>
> From experience, my requests are remarkably consistent, even if the
> same issues pop up with quite some time in-between.  You've just cited
> a similar discussion about NUL from more than a year ago, which I
> didn't event remember.
>
>> [Imagine if coding conventions changed like this.]
>
> They do, because standards.texi is actively maintained.  Things I've
> read and memorized years ago have changed, sometimes radically so, and
> I keep bumping into them when people say my code isn't according to
> GCS and cite from there.  That's life, and I accept it.

They don't change the way I was thinking of when I wrote that.
a) gdb's coding standards don't change that frequently.
b) they're documented.