Horton

Thread

Commits

  1. Fix some grammar and typos in comments and docs

  2. Fix a boatload of typos in C comments.

  1. bulk typos

    Justin Pryzby <pryzby@telsasoft.com> — 2018-03-31T10:56:40Z

    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

  2. Re: bulk typos

    Félix GERZAGUET <felix.gerzaguet@gmail.com> — 2018-03-31T11:17:04Z

    On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby@telsasoft.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

  3. Re: bulk typos

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-04-01T19:03:50Z

    =?UTF-8?Q?F=C3=A9lix_GERZAGUET?= <felix.gerzaguet@gmail.com> writes:
> On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby@telsasoft.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

  4. Re: bulk typos

    Andres Freund <andres@anarazel.de> — 2018-04-01T19:07:47Z

    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

  5. Re: bulk typos

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2018-04-01T21:11:27Z

    On 02/04/18 07:03, Tom Lane wrote:
> =?UTF-8?Q?F=C3=A9lix_GERZAGUET?= <felix.gerzaguet@gmail.com> writes:
>> On Sat, Mar 31, 2018 at 12:56 PM, Justin Pryzby <pryzby@telsasoft.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

  6. Re: bulk typos

    Justin Pryzby <pryzby@telsasoft.com> — 2020-10-25T19:48:49Z

    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.

  7. Re: bulk typos

    Heikki Linnakangas <hlinnaka@iki.fi> — 2020-10-25T21:00:33Z

    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

  8. Re: bulk typos

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-25T21:12:08Z

    Heikki Linnakangas <hlinnaka@iki.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

  9. Re: bulk typos

    Justin Pryzby <pryzby@telsasoft.com> — 2020-10-31T02:08:01Z

    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.

  10. Re: bulk typos

    Michael Paquier <michael@paquier.xyz> — 2020-11-02T06:22:03Z

    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