bulk typos

I needed another distraction so bulk-checked for typos, limited to comments in
*.[ch].

I'm not passionate about this, but it serves the purpose of reducing the
overhead of fixing them individually.

Also I heard something here recently about ugly languages..
time find . -name '*.c' -print0 |xargs -r0 sed -s '/.*\/\*/!d; s///; :l; /\*\/.*/!{N;b l}; s///; s/.*/\L&/' |grep -Eo '[[:alpha:]]{3,}' |sort |uniq -c |sort -nr |awk '$1==1{print $2}' |grep -xFvf /usr/share/dict/words |less

If any of these are disputed or objectionable, I would summarily discard them,
as I'm sure I missed some and fixing every last typo wasn't really the ghoul.

Justin

On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com>
wrote:

> I needed another distraction so bulk-checked for typos, limited to
> comments in
> *.[ch].
>

I think you introduced another one while changing "explcitly" to
"expilcitly" instead of "explicitly" :-)

--
Félix

=?UTF-8?Q?F=C3=A9lix_GERZAGUET?= <felix(dot)gerzaguet(at)gmail(dot)com> writes:
> On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com>
> wrote:
>> I needed another distraction so bulk-checked for typos, limited to
>> comments in *.[ch].

> I think you introduced another one while changing "explcitly" to
> "expilcitly" instead of "explicitly" :-)

LGTM for the most part, except for this change:

- * Therefore, we do not whinge about no-such-process.
+ * Therefore, we do not whine about no-such-process.

I think that spelling is intentional, so I didn't change it.
Pushed the rest, with Felix's correction.

regards, tom lane

Hi,

On 2018-03-31 05:56:40 -0500, Justin Pryzby wrote:
> --- a/src/backend/jit/llvm/llvmjit_expr.c
> +++ b/src/backend/jit/llvm/llvmjit_expr.c
> @@ -1768,7 +1768,7 @@ llvm_compile_expr(ExprState *state)
> b_compare_result,
> b_null);
>
> - /* build block analying the !NULL comparator result */
> + /* build block analyzing the !NULL comparator result */
> LLVMPositionBuilderAtEnd(b, b_compare_result);

Hah. I kinda like the previous way too ;)

Greetings,

Andres Freund

On 02/04/18 07:03, Tom Lane wrote:
> =?UTF-8?Q?F=C3=A9lix_GERZAGUET?= <felix(dot)gerzaguet(at)gmail(dot)com> writes:
>> On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com>
>> wrote:
>>> I needed another distraction so bulk-checked for typos, limited to
>>> comments in *.[ch].
>> I think you introduced another one while changing "explcitly" to
>> "expilcitly" instead of "explicitly" :-)
> LGTM for the most part, except for this change:
>
> - * Therefore, we do not whinge about no-such-process.
> + * Therefore, we do not whine about no-such-process.
>
> I think that spelling is intentional, so I didn't change it.
> Pushed the rest, with Felix's correction.
>
> regards, tom lane
>
Me thinks some people are Whinging far too much!

see: https://en.oxforddictionaries.com/definition/whinge

Cheers,
Gavin

On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
> I needed another distraction so bulk-checked for typos, limited to comments in
> *.[ch].
>
> I'm not passionate about this, but it serves the purpose of reducing the
> overhead of fixing them individually.

I happened across this old patch, so ran this again to find new typos.

There's a few that I don't know how best to fix.

Heikki, do you remember what this means ?
+++ b/src/backend/catalog/storage.c
+ * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear
+ * unbetimes. It'd probably be OK to keep it in TopTransactionContext,
+ * but I'm being paranoid.

Pavel, I can't understand this one.
I guess s/producement/producing/ is too simple of a fix.
Please check my proposed language.
+XmlTableFetchRow(TableFuncScanState *state)
+ * XmlTable returns table - set of composite values. The error context, is
+ * used for producement more values, between two calls, there can be
+ * created and used another libxml2 error context. ...

Surafel, this typo existed twice in the original commit (357889eb1).
One instance was removed by Tom in 35cb574aa. Should we simply fix the typo,
or borrow Julien/Tom's lanuage?
+ * Tuple at limit is needed for comparation in subsequent
+ * execution to detect ties.

On 25/10/2020 21:48, Justin Pryzby wrote:
> On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
>> I needed another distraction so bulk-checked for typos, limited to comments in
>> *.[ch].
>>
>> I'm not passionate about this, but it serves the purpose of reducing the
>> overhead of fixing them individually.
>
> I happened across this old patch, so ran this again to find new typos.

Nice script.

> There's a few that I don't know how best to fix.
>
> Heikki, do you remember what this means ?
> +++ b/src/backend/catalog/storage.c
> + * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear
> + * unbetimes. It'd probably be OK to keep it in TopTransactionContext,
> + * but I'm being paranoid.

Heh, even though I was the last one to touch that line according to git
blame, I just moved it from smgr.c. Looks like Tom wrote it in 2004. I
guess it means "too early". That would make sense from the context.
Google only gives a few hits but they seem to agree with "too early". A
very rare word, for sure. Might be good to change it to "too early", but
it's not wrong, and the poet in me kind of likes "unbetimes" :-).

- Heikki

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 25/10/2020 21:48, Justin Pryzby wrote:
>> Heikki, do you remember what this means ?
>> +++ b/src/backend/catalog/storage.c
>> + * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear
>> + * unbetimes. It'd probably be OK to keep it in TopTransactionContext,
>> + * but I'm being paranoid.

> Heh, even though I was the last one to touch that line according to git
> blame, I just moved it from smgr.c. Looks like Tom wrote it in 2004. I
> guess it means "too early". That would make sense from the context.

Sorry about that, I was being a little whimsical I suppose.

Doing a bit of research, I see the OED defines "betimes" as

[archaic] Before the usual or expected time; early.
‘next morning I was up betimes’

"unbetimes" doesn't seem to be a recognized word ... and now that I look
at this, if it did exist it would mean "too late" which is backwards.

I'd suggest "untimely" if you want to wax poetic, or "too soon" if
you prefer prose that plods.

regards, tom lane

On Sun, Oct 25, 2020 at 02:48:49PM -0500, Justin Pryzby wrote:
> On Sat, Mar 31, 2018 at 05:56:40AM -0500, Justin Pryzby wrote:
> > I needed another distraction so bulk-checked for typos, limited to comments in
> > *.[ch].
> >
> > I'm not passionate about this, but it serves the purpose of reducing the
> > overhead of fixing them individually.
>
> I happened across this old patch, so ran this again to find new typos.
>
> There's a few that I don't know how best to fix.

I've added a few more, but still not sure about these two.

> Pavel, I can't understand this one.
> I guess s/producement/producing/ is too simple of a fix.
> Please check my proposed language.
> +XmlTableFetchRow(TableFuncScanState *state)
> + * XmlTable returns table - set of composite values. The error context, is
> + * used for producement more values, between two calls, there can be
> + * created and used another libxml2 error context. ...
>
> Surafel, this typo existed twice in the original commit (357889eb1).
> One instance was removed by Tom in 35cb574aa. Should we simply fix the typo,
> or borrow Julien/Tom's lanuage?
> + * Tuple at limit is needed for comparation in subsequent
> + * execution to detect ties.

On Fri, Oct 30, 2020 at 09:08:01PM -0500, Justin Pryzby wrote:
> On Sun, Oct 25, 2020 at 02:48:49PM -0500, Justin Pryzby wrote:
>> Pavel, I can't understand this one.
>> I guess s/producement/producing/ is too simple of a fix.
>> Please check my proposed language.
>> +XmlTableFetchRow(TableFuncScanState *state)
>> + * XmlTable returns table - set of composite values. The error context, is
>> + * used for producement more values, between two calls, there can be
>> + * created and used another libxml2 error context. ...
>>
>> Surafel, this typo existed twice in the original commit (357889eb1).
>> One instance was removed by Tom in 35cb574aa. Should we simply fix the typo,
>> or borrow Julien/Tom's lanuage?
>> + * Tuple at limit is needed for comparation in subsequent
>> + * execution to detect ties.

What you have sent for xml.c is a clear improvement, but I am not sure
if that's the best we can do. So I have left this part out, and
applied the rest.

PS: I am also quite fond of "unbetimes".
--
Michael