On 2020-01-15 13:57, Richard Hainsworth wrote:
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.
Richard,
Are you tied to a chair and someone is forcing you
to listen to my eMails? Do we need to call 911? If you
do not like what I write, killfile me.
You don't like me. There is nothing I can do about that.
Please do not involve the rest of this group with your own
personal distaste of me or anyone else.
And that post required that I lay out the specifications
of string in C. Sorry it required so many words, but
it did.
And, by the way, I'd never make you listen to my
eMail letter after tying you up. I call Hong Kong on your
cell phone, over and over and over until you screamed.
Okay, Mr. Humor Impaired, tell me how offensive that joke
was.
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)
As David Letterman use to say when folks complained about
his jokes "how much did you pay to listen to them".
I like JJ and was trying to lighten the mood. If I
were to say the sky was a lovely shade of blue, you
find something offensive in it.
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.
No fooling.
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.
Yes it is a problem if using the documentation sets you down
a bad path. NativeCall interfaces with C, so you better
inform the read as to what those requirements are. Not
give examples that do not work in practice.
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.
I would be fine with that. This is how I write it in my
own documentation:
Raku strings and “C” strings are two vastly different
things. A Raku string is a data “structure”. By
definition, a “C” string is an array of characters
terminated with nul, chr(0) (0x00). You have to
convert Raku strings into a “C” string format usable
by NativeCall:
Use the following to convert to a "C" string and
then tack a nul on the end:
Note: if the function name has a “W” at the end, use UTF16
UTF8: my $L = CArray[uint8].new("abcdefg".encode.list);
$L[$L.elems] = 0;
UTF16: my $M = CArray[uint16].new("abcdefg".encode.list);
$M[$M.elems] = 0;
Note: you can't use `push` as it is an "immutable 'List'"
Note: a UTF C string is “little-endian” meaning “ABC” is
represented as 0x4200 (A), 0X4300 (B), 0X4400 (C),
0x0000 (nul)
I go on to give same subs to do the conversion for you.
c) You could provide a useful service to the Raku community by offering
a PR (Github Pull Request) with a patch.
Got to get past JJ first. Once he give approval, then I
would LOVE to contribute.
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.
Well then you forgot the part about Strings heeding to be
terminated with a nul and the difference between Strings and
String Literals.
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.
That is why I quoted:
INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:201x
Programming languages — C
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
5.2.1 Character sets and 7.1.1 Definitions of terms
So that those folks could see exactly what C does.
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.
If I can't get it past JJ's, I can't get it into
the system. He is the first responder, so to speak.
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.
Actually, I appreciate when folks find my mistakes. But
do or best to be a gentleman.
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.)
English is my only language. I forgot the "ing". I do
make a lot of typos. The Windows folks get a big chuckle
when I forget the "n" in Windows.
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.
Uhhh. JJ did not understand the spec. He has stated so.
So I took considerable time to look them up for him.
That you do not like the way I phrased it, there is
really nothing I can do about it. Again, if I was
to say the sky was a lovely shade of blue, you'd
find something in it offensive.
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:
No it is not.
"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!
When you use NativeCall, you have to format things such
that C understands them. This is why you need to
know what the spec is. The documentation does not do that.
In Pascal or BASIC strings have different characteristics. It is not the
place in Raku documentation to discuss other languages.
There we disagree. If the documentation is speaking
of how to interface with C functions, you are damned tootin'
got to discuss what you need to know.
Then again, if you are not discussing how to interface with C functions,
then by all mean, leave out any discussion of C
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.
Damned tootin' it is a bug. If you can not properly
interface with C function IT'S A BUG.
Do you want folks tp be able to use NativeCall or not?
You to properly document what they need, not leave
them flapping in the wind like I had to do.
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.
uuuh. NativeCall is ABOUT BOTH. You have to discuss BOTH
and how they relate to each other. Do you want folks to
be able to use NativeCall or not?
As far as I can tell, NativeCall is written pretty well.
It is the documentation that is miserable. Did that word
offend you somehow?
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.
And you would think that the NativeCall documentation would
make that clear, but does not.
But adding to the Raku documentation to reflect that counts as an
ENHANCEMENT to the documentation, not a Bug.
Got to get past JJ first.
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?"
That was meant in friendship to JJ. Again, if I was to say
the sky was a lovely shade of blue, you'd find offense
with it. The above twist and mangle is a good example.
Is there not a 'Golden Rule' in your part of the world about doing unto
others as you would be done by?
And that includes not mangling other people's words
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.
Wouldn't do you any good to mention the traits of that animal, would it?
And was is also an inside comment in friendship
to JJ. But that damned blue sky thing again. Twist, turn,
mangle.
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
Well then, if you are the one who wrote the NativeCall
documentation, would you be able to put aside your personal
distaste of me and read it to see of you would be to
use it in your next iteration?
Kaisen. It is a wonderful thing. Raku is a SHINING example
of it as is the Linux kernel.
-T
