I join with Liz and Tom to thank you, Richard, for this long and thoughtful answer.
Le mer. 15 janv. 2020 à 22:57, Richard Hainsworth <rnhainswo...@gmail.com> a écrit : > 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 >
