Thank you Richard for this long and thoughtful answer. I have already given up on Todd, I'm glad to see others haven't (yet). What will follow is probably a response that is either: a. everybody is against me, b. the Raku community won't listen, c. the various variations on those themes. I sincerely hope that I'm wrong.
Liz > On 15 Jan 2020, at 22:57, Richard Hainsworth <rnhainswo...@gmail.com> 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. > > 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
