Thread: [MASSMAIL]Typos in the code and README

Now that the tree has settled down a bit post-freeze I ran some tooling to
check spelling.  I was primarily interested in docs and README* which were
mostly free from simply typos, while the code had some in various comments and
one in code.  The attached fixes all that I came across (not cross-referenced
against ongoing reverts or any other fixup threads but will be before pushing
of course).

--
Daniel Gustafsson

On 2024-04-11 Th 09:05, Daniel Gustafsson wrote:
> Now that the tree has settled down a bit post-freeze I ran some tooling to
> check spelling.  I was primarily interested in docs and README* which were
> mostly free from simply typos, while the code had some in various comments and
> one in code.  The attached fixes all that I came across (not cross-referenced
> against ongoing reverts or any other fixup threads but will be before pushing
> of course).



I have these covered:


src/test/modules/test_json_parser/README                  | 2 +-
.../test_json_parser/test_json_parser_incremental.c       | 4 ++--
src/test/modules/test_json_parser/test_json_parser_perf.c | 2 +-


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
>     On 11 Apr 2024, at 15:29, David Rowley <dgrowleyml@gmail.com> wrote:
> 
>     On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, <daniel@yesql.se> wrote:
> 
>         Now that the tree has settled down a bit post-freeze I ran some tooling
>         to
>         check spelling.  I was primarily interested in docs and README* which
>         were
>         mostly free from simply typos, while the code had some in various
>         comments and
>         one in code.  The attached fixes all that I came across (not
>         cross-referenced
>         against ongoing reverts or any other fixup threads but will be before
>         pushing
>         of course).
> 
> 
>     I see you've corrected "iif" to "if". It should be "iff".
> 
> 
> Gotcha, will fix.  I opted for "if" due to recent threads where the use of
> "iff" was discouraged due to not being commonly known, but that was in doc/ and
> not code comments.

I actually agree "iff" is just not clear enough.  "Iff" stands for "if
and only if" and maybe should be spelled out that way.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

On Fri, Apr 12, 2024 at 04:55:16PM -0400, Bruce Momjian wrote:
> On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> >     On 11 Apr 2024, at 15:29, David Rowley <dgrowleyml@gmail.com> wrote:
> > 
> >     On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, <daniel@yesql.se> wrote:
> > 
> >         Now that the tree has settled down a bit post-freeze I ran some tooling
> >         to
> >         check spelling.  I was primarily interested in docs and README* which
> >         were
> >         mostly free from simply typos, while the code had some in various
> >         comments and
> >         one in code.  The attached fixes all that I came across (not
> >         cross-referenced
> >         against ongoing reverts or any other fixup threads but will be before
> >         pushing
> >         of course).
> > 
> > 
> >     I see you've corrected "iif" to "if". It should be "iff".
> > 
> > 
> > Gotcha, will fix.  I opted for "if" due to recent threads where the use of
> > "iff" was discouraged due to not being commonly known, but that was in doc/ and
> > not code comments.
> 
> I actually agree "iff" is just not clear enough.  "Iff" stands for "if
> and only if" and maybe should be spelled out that way.

Just to clarify, I think "if and only if" means "if A then B" and B can
only happen if A happens, meaning there are not other cases where B can
happen.  This latter part is what disinguishes "iff" from "if".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

On 11/04/2024 16:05, Daniel Gustafsson wrote:
> Now that the tree has settled down a bit post-freeze I ran some tooling to
> check spelling.  I was primarily interested in docs and README* which were
> mostly free from simply typos, while the code had some in various comments and
> one in code.  The attached fixes all that I came across (not cross-referenced
> against ongoing reverts or any other fixup threads but will be before pushing
> of course).

Here's a few more. I've accumulate these over the past couple of months, 
keeping them stashed in a branch, adding to it whenever I've spotted a 
minor typo while reading the code.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 11/04/2024 16:05, Daniel Gustafsson wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling.  I was primarily interested in docs and README* which were
>> mostly free from simply typos, while the code had some in various comments and
>> one in code.  The attached fixes all that I came across (not cross-referenced
>> against ongoing reverts or any other fixup threads but will be before pushing
>> of course).
>
> Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding to
itwhenever I've spotted a minor typo while reading the code. 

Nice, let's lot all these together.

--
Daniel Gustafsson

On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit whenever I've spotted a minor typo while reading the code.
 
>
> Nice, let's lot all these together.

Here are a few additional ones to add to that.

Found with a manual trawl through git grep -E
'\b([a-zA-Z]{2,}[^long|^that])\s+\1\b' -- ':!*.po' ':!*.dat'

David

> On 14 Apr 2024, at 13:19, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>>> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit whenever I've spotted a minor typo while reading the code. 
>>
>> Nice, let's lot all these together.
>
> Here are a few additional ones to add to that.

Thanks.  Collecting all the ones submitted here, as well as a few submitted
off-list by Alexander, the patch is now a 3-part patchset of cleanups:

0001 contains the typos and duplicate words fixups, 0002 fixes a parameter with
the wrong name in the prototype and 0003 removes a leftover prototype which was
accidentally left in a refactoring.

--
Daniel Gustafsson

Hi,

Thanks for working on this!

On Mon, 15 Apr 2024 at 15:26, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 14 Apr 2024, at 13:19, David Rowley <dgrowleyml@gmail.com> wrote:
> >
> > On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
> >>
> >>> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> >>> Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit whenever I've spotted a minor typo while reading the code.
 
> >>
> >> Nice, let's lot all these together.
> >
> > Here are a few additional ones to add to that.
>
> Thanks.  Collecting all the ones submitted here, as well as a few submitted
> off-list by Alexander, the patch is now a 3-part patchset of cleanups:
>
> 0001 contains the typos and duplicate words fixups, 0002 fixes a parameter with
> the wrong name in the prototype and 0003 removes a leftover prototype which was
> accidentally left in a refactoring.

I realized two small typos: 'sgmr' -> 'smgr'. You may want to include
them in 0001.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

> On 16 Apr 2024, at 15:37, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

> I realized two small typos: 'sgmr' -> 'smgr'. You may want to include
> them in 0001.

Thanks, I incorporated these into 0001 before pushing.  All the commits in this
patchset are now applied.

--
Daniel Gustafsson

On Fri, 19 Apr 2024 at 20:13, Daniel Gustafsson <daniel@yesql.se> wrote:
> Thanks, I incorporated these into 0001 before pushing.  All the commits in this
> patchset are now applied.

Here are a few more to see if it motivates anyone else to do a more
thorough search for another batch.

Fixes duplicate words spanning multiple lines plus an outdated
reference to "streaming read" which was renamed to "read stream" late
in that patch's development.

duplicate words found using:
ag "\s([a-zA-Z]{2,})[\s*]*\n\1\b"
ag "\s([a-zA-Z]{2,})\n(\s*\*\s*)\1\b"

David

On Sat, 20 Apr 2024 at 16:09, David Rowley <dgrowleyml@gmail.com> wrote:
> Here are a few more to see if it motivates anyone else to do a more
> thorough search for another batch.

I've pushed these now.

David

Hello,

28.04.2024 11:05, David Rowley wrote:

> On Sat, 20 Apr 2024 at 16:09, David Rowley <dgrowleyml@gmail.com> wrote:
>> Here are a few more to see if it motivates anyone else to do a more
>> thorough search for another batch.
> I've pushed these now.

Please look also at the list of other typos and inconsistencies I've found
on the master branch:
additional_notnulls -> old_notnulls (cf. b0e96f311)
ATAddCheckConstraint ->? ATAddCheckNNConstraint (cf. b0e96f311)
bt_page_check -> bt_target_page_check (cf. 5ae208720)
calblack_arg -> callback_arg
combinig -> combining
compaining -> complaining
ctllock - remove (cf. 53c2a97a9)
dabatase -> database
eval_const_exprs_mutator -> eval_const_expressions_mutator
ExecEndValuesScan - remove (cf. d060e921e)
get_json_nested_columns -> get_json_table_nested_columns
io_direct -> debug_io_direct
iS ->? IS (a neatnik-ism)
joing ->? join (cf. 20f90a0e4)
_jumbleRangeTblEntry - remove (cf. 367c989cd)
Mallroy -> Mallory
onstead -> instead
procedual -> procedural
psql_safe -> safe_psql
read_quoted_pattern -> read_quoted_string
repertiore -> repertoire
rightfirstdataoffset ->? rightfirstoffset (cf. 5ae208720)
Sincle ->? Since (perhaps the whole sentence could be rephrased)
sslnegotition=direct/requiredirectwould -> sslnegotiation=direct/requiredirect would
sslnegotitation -> sslnegotiation
walreciever -> walreceiver
xid_wrapround -> xid_wraparound

(some of them are located in doc/, so it's not a code-only change)
I've attached the patch for your convenience, though maybe some
of the suggestions are to be discarded.

Best regards,
Alexander

On Fri, 3 May 2024 at 00:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> (some of them are located in doc/, so it's not a code-only change)
> I've attached the patch for your convenience, though maybe some
> of the suggestions are to be discarded.

Thanks. I was hoping you'd do that.

I pushed the patch after only adjusting the path in the docs which had
"module" rather than "modules".

David

Hello hackers,

03.05.2024 17:36, David Rowley wrote:
> I pushed the patch after only adjusting the path in the docs which had
> "module" rather than "modules".

Please look at another bunch of inconsistencies/orphaned entities I found
in the tree, with the possible substitutions:
errmsg_buf -> errormsg_buf
(coined by 6b18b3fe2)

NoMovementScanDirectionScans -> NoMovementScanDirection
(introduced with e9aaf0632, discussed in [1], but still seems inaccurate)

XLogReadRecordInternal -> XLogReadRecord
(from 3f1ce9734, align with a comment above: "Start and end point of last
record returned by XLogReadRecord().")

BYPASS_ALLOWCONN -> BGWORKER_BYPASS_ROLELOGINCHECK (see 492217301)

xs_ctup.t_self -> xs_heaptid (see c2fe139c2 and 304532421)

pgStatShmLookupCache -> pgStatLocal.shmem (coined by 5891c7a8e)

smgr_fsm_nblocks and smgr_vm_nblocks -> smgr_cached_nblocks
(see the same comment updated by c5315f4f4)

XID becomes older than GlobalXmin -> XID becomes visible to everyone
(in accordance with dc7420c2c9 src/backend/access/gist/gistutil.c)

gen-rtab - remove (non-existing since db7d1a7b0)

BARRIER_SHOULD_CHECK - remove (unused since a3ed4d1ef)

EXE_EXT - remove (unused since f06b1c598)

endterm - remove
(see 60c90c16c -- Use xreflabel attributes instead of endterm ...)

xl_commit_ts_set, SizeOfCommitTsSet - remove (unused since 08aa89b32)

The corresponding patch is attached for your convenience.

[1] https://www.postgresql.org/message-id/20230131140224.7j6gbcsfwmad2a4b%40liskov

Best regards,
Alexander

> On 4 Jul 2024, at 19:00, Alexander Lakhin <exclusion@gmail.com> wrote:

> Please look at another bunch of inconsistencies/orphaned entities I found
> in the tree, with the possible substitutions:

Thanks for these, and sorry for the delay in processing them (summer happened
etc).  I've started to go through them and have applied some low-hanging fruit
already, will go over all them.

--
Daniel Gustafsson

(I know Daniel mentioned he'd get to these, but the ScanDirection one
was my fault and I needed to clear that off my mind. I did a few
others while on this topic.)

On Fri, 5 Jul 2024 at 05:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> Please look at another bunch of inconsistencies/orphaned entities I found
> in the tree, with the possible substitutions:
> errmsg_buf -> errormsg_buf
> (coined by 6b18b3fe2)

Fixed.

> NoMovementScanDirectionScans -> NoMovementScanDirection
> (introduced with e9aaf0632, discussed in [1], but still seems inaccurate)

Oops. Fixed.

> XLogReadRecordInternal -> XLogReadRecord
> (from 3f1ce9734, align with a comment above: "Start and end point of last
> record returned by XLogReadRecord().")

Fixed.

> BYPASS_ALLOWCONN -> BGWORKER_BYPASS_ROLELOGINCHECK (see 492217301)

Fixed

> xs_ctup.t_self -> xs_heaptid (see c2fe139c2 and 304532421)

Fixed.

> pgStatShmLookupCache -> pgStatLocal.shmem (coined by 5891c7a8e)

Fixed.

> smgr_fsm_nblocks and smgr_vm_nblocks -> smgr_cached_nblocks
> (see the same comment updated by c5315f4f4)

Heikki fixed in 19de089cd.

> XID becomes older than GlobalXmin -> XID becomes visible to everyone
> (in accordance with dc7420c2c9 src/backend/access/gist/gistutil.c)

I'd need to spend more time to understand this.

> gen-rtab - remove (non-existing since db7d1a7b0)

Daniel fixed in cc59f9d0f.

> BARRIER_SHOULD_CHECK - remove (unused since a3ed4d1ef)

I wasn't sure if nothing else external could be using this. The macro
doesn't use any fields that are now gone, so I'm not confident enough
to remove it. Can Robert confirm?

> EXE_EXT - remove (unused since f06b1c598)

Daniel fixed in 88e3da565.

> endterm - remove
> (see 60c90c16c -- Use xreflabel attributes instead of endterm ...)

I read that commit message and I agree it's now unused. I just didn't
get any vibes from the commit message that it shouldn't ever be used
again.  Can Tom confirm?

> xl_commit_ts_set, SizeOfCommitTsSet - remove (unused since 08aa89b32)

I would say it should be removed.  I just didn't because the commit I
had pending fitted into the "typos" category and this didn't quite
fit.

I've attached a patch with the remainder.

David

> On 3 Sep 2024, at 07:51, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 03, 2024 at 02:24:32PM +0900, Michael Paquier wrote:
>> On Mon, Sep 02, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
>>> I've gathered another bunch of defects with the possible substitutions.
>>> Please take a look:
>>> pgstat_add_kind -> pgstat_register_kind (see 7949d9594)
>>
>> And here I thought I took care of these inconsistencies.  This one is
>> on me so I'll go fix that in a bit, with the rest while on it.
>
> And done that.
>
> The bit about CommitTSSLRU -> CommitTsSLRU in lwlock.c should be
> backpatched down to 17, indeed, but the branch is frozen until the RC
> tag lands in the tree, so I have left it out for now. The tag should
> show up tomorrow or so.  Good thing that you have noticed this issue
> before the release.

I see your v17 typo fixes, and raise you a few more.  Commit 31a98934d169 from
just now contains 2 (out of 3) sets of typos introduced in v17 so they should
follow along when you push the ones mentioned here.

--
Daniel Gustafsson

> On 4 Sep 2024, at 03:25, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 03, 2024 at 12:00:13PM +0200, Daniel Gustafsson wrote:
>> I see your v17 typo fixes, and raise you a few more.  Commit 31a98934d169 from
>> just now contains 2 (out of 3) sets of typos introduced in v17 so they should
>> follow along when you push the ones mentioned here.
>
> Is that really mandatory?  I tend to worry about back branches only
> when this stuff is user-visible, like in the docs or error messages.
> This opinion varies for each individual, of course.  That's just my
> lazy opinion.

Not mandatory at all, but since you were prepping a typo backpatch anyways I
figured these could join to put a small dent in reducing risks for future
backports.

--
Daniel Gustafsson

On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson <daniel@yesql.se> wrote:
> Not mandatory at all, but since you were prepping a typo backpatch anyways I
> figured these could join to put a small dent in reducing risks for future
> backports.

I think this is pretty good logic.  I think fixing comment typos in
ancient code and backpatching to all supported versions isn't good use
of time, but fixing a typo in "recent" code and backpatching to where
that code was added seems useful. Newer code is more likely to need
bug fixes in the future, so going to a bit more effort to make
backpatching those bug fixes easier seems worth the effort.  I just
don't know what "recent" should be defined as. I'd say if it's in a
version we've not released yet, that's probably recent. By the time .1
is out, there's less chance of bugs in new code. Anyway, I doubt hard
guidelines are warranted here, but maybe some hints about best
practices in https://wiki.postgresql.org/wiki/Committing_checklist ?

David

> On 4 Sep 2024, at 17:34, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson <daniel@yesql.se> wrote:
>> Not mandatory at all, but since you were prepping a typo backpatch anyways I
>> figured these could join to put a small dent in reducing risks for future
>> backports.
>
> I think this is pretty good logic.  I think fixing comment typos in
> ancient code and backpatching to all supported versions isn't good use
> of time, but fixing a typo in "recent" code and backpatching to where
> that code was added seems useful. Newer code is more likely to need
> bug fixes in the future, so going to a bit more effort to make
> backpatching those bug fixes easier seems worth the effort.

Absolutely agree.

> I just don't know what "recent" should be defined as. I'd say if it's in a
> version we've not released yet, that's probably recent. By the time .1
> is out, there's less chance of bugs in new code. Anyway, I doubt hard
> guidelines are warranted here, but maybe some hints about best
> practices in https://wiki.postgresql.org/wiki/Committing_checklist ?

That sounds like a good idea.  Off the cuff I would agree that unreleased
versions and .0 versions are strong candidates (but not mandatory) for trivial
backpatches like typos, beyond that the value is likely to be lower.

--
Daniel Gustafsson

On Thu, 2 Jan 2025 at 05:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> Please look at another collection of typos and inconsistencies introduced
> during 2024:

The fixes all look good to me. I see some are mine, so I will take
care of pushing.

Thanks for the patch.

David