Todd,
Once again I find myself writing to you directly in response to a post
of yours and asking again that you be respectful to others in this
community. Striving for respect for everyone from everyone directly
benefits us all.
And disrespect harms you: your long emails defending your points of view
have no persuasive power because you refuse to listen or to change.
Further the self-aggrandising tone and disrespect to others are - to be
quite blunt - also consistent with the word and phrases one might
consider to be indicative of the intellectually challenged. It might be
wise therefore to re-parse your responses before sending lest the
readers of this list find their perceptions harden into belief.
You have asked in response to a previous thread that if you are
disrespectful, that it be pointed out. So here goes.
On 15/01/2020 18:13, ToddAndMargo via perl6-users wrote:
On 2020-01-14 01:13, JJ Merelo wrote:
Never miss a good chance to bash documentation...
Guilty as charged?
No one has ever called the documentation perfect, but there is only one
person who goes beyond the reasonable to vilify both the documentation
and its volunteer creators.
Guilty as charged! (An indication of humility as well as humour on your
part would have been to replace the '?' with ':)' or some such emoji)
By the way, "C String" REQUIRES a nul at the end:
an error in the NativeCall documentation.
No, it does not. And even if it did, it should better go to the C,
not Raku, documentation
Your original complaint was that you had encountered a problem with '\0'
on strings and you wanted that problem to be included in the Raku
documentation.
a) Irrespective of whether null-ended strings are a part of C or an
implementation detail, it is not a Raku problem. So of the two
assertions that JJ made, one might be debatable within the context of a
C-language based list, not a Raku list, and the second is True about
reference materials in Raku, but arguably the tutorial materials could
be enhanced.
b) The way in which you present your point of view is
counter-productive. I would agree with you that for irregular users of C
working with some libraries, strings without '\0' terminations could
trigger unexpected responses. It would be useful, therefore, if at an
appropriate point in the NativeCall POD file, a comment is included to
this effect.
c) You could provide a useful service to the Raku community by offering
a PR (Github Pull Request) with a patch.
d) Within the NativeCall POD there is a fairly extended tutorial about
interfacing to an Internet function in a C library. I wrote that part of
the document, having myself worked hard to get the function to work. I
documented my work, created a patch and offered it to the Perl 6
community. I think it was my first patch. It was accepted. The
documentation can be changed by newcomers. So long as the contributor is
willing to LISTEN to requests for changes, as in grammar and spelling.
Or in placing. By way of another example, I wrote a fairly long document
about CompUnits, submitted a PR, which was not accepted. So be it. I
understood the rationale for the rejection.
Oh Great And Mighty Gatekeeper of the Documentation!
This is plain disrespect. Calling JJ a dog was also disrespectful.
Reversing a derogatory term for hyperbole is no less disrespectful.
You are in error. The problem is the mistake in the
documentation
Several people have pointed out to you that they do not consider your
interpretation of C to be definitive. Nor does it matter. What I could
agree on (as said above) is that there are peculiarities of some
versions of C that can trip the unwary, and that the TUTORIALS about an
interface system, such as NativeCall, could include mention of the trap.
you won't fix
It is not JJ's job to FIX the documentation. He has provided substantial
and significant contributions to the documentation system as a whole. I
am profoundly grateful to JJ for his efforts.
You could also contribute to the community generated documentation by
providing a PR.
And please do not refer to your own reference notes. If you do in this
thread, I will not refrain, as I have done so far, in subjecting them to
the sort of searing review they deserve.
and your misunderstand of
the C programming language.
Once again this is disrespectful. (In case English is your second
language, I will not point out the grammatical error.) Since you were
obviously not given any lessons in etiquette during your long life,
perhaps a little pointer would be in order here. Rather than directly
accusing someone of being in error, or of misunderstanding something,
and thereby diminishing that person in a public forum, a less aggressive
approach would be to say "I don't think I agree with you" and then state
the facts as you see them. In this way, if the person you are
communicating with changes his/her mind to acknowledge you are correct,
it is easy for that person to say so. By claiming the person is in error
outright, you introduce emotion and the necessity of admitting to being
less than you in some respect. To show grace and humility is an
effective way of demonstrating intellectual strength, whilst harping on
about minutiae without conceding a bigger context is a sign of a limited
understanding about the context.
INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:201x
Programming languages — C
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
<snip bloat, a link would have been sufficient>
You are basically confusing a "String" with a "String literal".
This is disrespectful. It would have been far more persuasive to say
something along the lines of:
"The C language documentation makes a distinction between a String and a
String literal and so ...".
They are two different things.
In C! We are discussing Raku documentation where strings are objects,
and can contain zero or more characters and characters that conform to
Unicode. Indeed manipulating Unicode makes Raku better than any other
language out there!
In Pascal or BASIC strings have different characteristics. It is not the
place in Raku documentation to discuss other languages.
A String Literal can have
nuls in them that are part of the string literal. And
with a string literal, you have to also keep track of the
length of the string literal.
in C!
In WinAPI, calls
<snip bloat that shows you have grokked Strings in Windows C>
Your holding on to NOT-A-BUG
It is not a bug! By definition. The way C handles strings is not the way
Raku handles strings.
Raku handles strings in a clearly defined manner and it adheres to those
definitions. No bug in Raku.
Perhaps if you were to indicate how string termination is mis-handled
inside a Raku program, it would be possible to discuss whether there is
a problem with NativeCall, but so far you have not made or justified
such a claim.
Not a bug in Raku documentation, which is about Raku, not C.
I will grant you that it would be HELPFUL to another person interfacing
a Raku program with C to be aware that there are specific differences in
string handling. I seem to remember coming across a problem like that
when I used a Raku program to interface to another C library, but since
anyone who has worked with C strings in such contexts knows that they
cause problems, it is the first place to look.
But adding to the Raku documentation to reflect that counts as an
ENHANCEMENT to the documentation, not a Bug.
will mean that everyone
using the documentation will have to figure this all
out the hard way, as I did.
And when others have learnt something the hard way, they have
contributed a part of that knowledge to the community. You could do that
by writing a patch and making a PR.
Oh great and exalted Gatekeeper, today you get a C-.
Minus for meanness.
Once again this is really disrespectful and is harmful to the Raku
community. JJ volunteers significant time and effort in contributing to
the Raku community. These comments of yours are very likely to piss off
even a humorous and understanding person, and if it were you in his
place, you would probably say something along the lines of "WTF, for
what do I do this work? So some shmuck on the other side of the world
can critique me? I English his first language?"
Is there not a 'Golden Rule' in your part of the world about doing unto
others as you would be done by?
Your favorite Golden Retriever,
-T
You probably don't want to know what image of you as an animal after
reading a post like this.
Your questions about Raku / Perl 6 in the past have produced some really
interesting answers, and I have learnt a lot from the answers you have
got, and written modules as a result. Your ability to ask questions is
quite unique.
For this reason, I have again responded to a post of yours. If you were
to change the way you interact on this mail list, your enthusiasm and
pragmatic approach would be light upon light.
Regards,
Richard
aka finanalyst
