Re: problems with xor
On 2020-01-17 9:00 p.m., ToddAndMargo via perl6-users wrote: Still don't know what they used the word "sub" The term "sub" is short for "subroutine", and declaring routines that way is part of the Perl legacy that lasted into Raku. -- Darren Duncan
Re: problems with xor
On 2020-01-17 21:43, Paul Procacci wrote: Apocalypse 3: "/operators are just funny/ looking /function/ calls" Chuckle!
Re: problems with xor
Apocalypse 3:
"*operators are just funny* looking *function* calls"
On Sat, Jan 18, 2020 at 12:31 AM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> On 2020-01-17 20:49, Kevin Pye wrote:
> > In Raku, all operators are just functions with a funny syntax
>
> I like the way you wrote that. Your technical
> writing just got some fan mail.
>
--
__
:(){ :|:& };:
Re: problems with xor
On 2020-01-17 20:49, Kevin Pye wrote: In Raku, all operators are just functions with a funny syntax I like the way you wrote that. Your technical writing just got some fan mail.
Re: problems with xor
On 2020-01-17 20:49, Kevin Pye wrote: n Raku, all operators are just functions with a funny syntax, but if you want to use it as a function, you need the full name. infix:<+^>($x, $y) would probably work just as well. $z = +^($x, $y) no work so well. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = +^($x, $y); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' 01010111 1101 And where is the '$' before the z? ya, I just found the missing $ :'(
Re: problems with xor
On 2020-01-17 20:43, ToddAndMargo via perl6-users wrote: On Sat, 18 Jan 2020 at 15:03, ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: Hi All, https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT (Operators) infix +^§ multi sub infix:<+^>($a, $b --> Int:D) Integer bitwise XOR operator: Coerces both arguments to Int and does a bitwise XOR (exclusive OR) operation. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' 01010111 1101 XOR A B A xor B 0 0 0 1 0 1 0 1 1 1 1 0 That s not what I am seeing above. What am I doing wrong this time? And who set the high bit making $z negative? Many thanks, -T On 2020-01-17 20:15, Kevin Pye wrote: As you say, +^ is an infix operator. Why are you trying to use it as a function? Because of the word "sub" in the following multi sub infix:<+^>($a, $b --> Int:D) Try $z = $x +^ $y. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = $x +^ $y; say "0", $x.base(2); say "", $y.base(2); say z.base(2);' ===SORRY!=== Error while compiling -e Undeclared routine: z used at line 1 Thank you for the help. Oops. goof on my part: $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = $x +^ $y; say "0", $x.base(2); say "", $y.base(2); say "0",$z.base(2);' 01010111 01011000 Still don't know what they used the word "sub"
Re: problems with xor
In Raku, all operators are just functions with a funny syntax, but if you want to use it as a function, you need the full name. infix:<+^>($x, $y) would probably work just as well. And where is the '$' before the z? On Sat, 18 Jan 2020 at 15:45, ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > >> On Fri, Jan 17, 2020 at 11:03 PM ToddAndMargo via perl6-users > >> mailto:perl6-users@perl.org>> wrote: > >> > >> Hi All, > >> > >> https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT > >> > >> (Operators) infix +^§ > >> > >> multi sub infix:<+^>($a, $b --> Int:D) > >> > >> Integer bitwise XOR operator: Coerces both arguments to Int and > does a > >> bitwise XOR (exclusive OR) operation. > >> > >> > >> $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 > $z = > >> +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say > >> $z.base(2);' > >> > >> 01010111 > >> > >> 1101 > >> > >> > >> XOR > >> A B A xor B > >> 0 0 0 > >> 1 0 1 > >> 0 1 1 > >> 1 1 0 > >> > >> That s not what I am seeing above. > >> > >> What am I doing wrong this time? > >> > >> And who set the high bit making $z negative? > >> > >> Many thanks, > >> -T > > > On 2020-01-17 20:24, Paul Procacci wrote: > > multi sub infix:<+^>($a, $b-->Int:D) > > > > > > _infix_ here is the keyword for you. > > > > my uint8 $z = $x +^ $y; > > $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = > $x +^ $y; say "0", $x.base(2); say "", $y.base(2); say z.base(2);' > ===SORRY!=== Error while compiling -e > Undeclared routine: > z used at line 1 > > What does "sub" stand for? >
Re: problems with xor
On Fri, Jan 17, 2020 at 11:03 PM ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: Hi All, https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT (Operators) infix +^§ multi sub infix:<+^>($a, $b --> Int:D) Integer bitwise XOR operator: Coerces both arguments to Int and does a bitwise XOR (exclusive OR) operation. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' 01010111 1101 XOR A B A xor B 0 0 0 1 0 1 0 1 1 1 1 0 That s not what I am seeing above. What am I doing wrong this time? And who set the high bit making $z negative? Many thanks, -T On 2020-01-17 20:24, Paul Procacci wrote: multi sub infix:<+^>($a, $b-->Int:D) _infix_ here is the keyword for you. my uint8 $z = $x +^ $y; $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = $x +^ $y; say "0", $x.base(2); say "", $y.base(2); say z.base(2);' ===SORRY!=== Error while compiling -e Undeclared routine: z used at line 1 What does "sub" stand for?
Re: problems with xor
On Sat, 18 Jan 2020 at 15:03, ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: Hi All, https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT (Operators) infix +^§ multi sub infix:<+^>($a, $b --> Int:D) Integer bitwise XOR operator: Coerces both arguments to Int and does a bitwise XOR (exclusive OR) operation. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' 01010111 1101 XOR A B A xor B 0 0 0 1 0 1 0 1 1 1 1 0 That s not what I am seeing above. What am I doing wrong this time? And who set the high bit making $z negative? Many thanks, -T On 2020-01-17 20:15, Kevin Pye wrote: As you say, +^ is an infix operator. Why are you trying to use it as a function? Because of the word "sub" in the following multi sub infix:<+^>($a, $b --> Int:D) Try $z = $x +^ $y. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = $x +^ $y; say "0", $x.base(2); say "", $y.base(2); say z.base(2);' ===SORRY!=== Error while compiling -e Undeclared routine: z used at line 1 Thank you for the help.
Re: problems with xor
multi sub infix:<+^>($a, $b --> Int:D)
_infix_ here is the keyword for you.
my uint8 $z = $x +^ $y;
On Fri, Jan 17, 2020 at 11:03 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> Hi All,
>
> https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT
>
> (Operators) infix +^§
>
> multi sub infix:<+^>($a, $b --> Int:D)
>
> Integer bitwise XOR operator: Coerces both arguments to Int and does a
> bitwise XOR (exclusive OR) operation.
>
>
> $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z =
> +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);'
>
> 01010111
>
> 1101
>
>
> XOR
> A B A xor B
> 0 0 0
> 1 0 1
> 0 1 1
> 1 1 0
>
> That s not what I am seeing above.
>
> What am I doing wrong this time?
>
> And who set the high bit making $z negative?
>
> Many thanks,
> -T
>
--
__
:(){ :|:& };:
Re: problems with xor
As you say, +^ is an infix operator. Why are you trying to use it as a function? Try $z = $x +^ $y. On Sat, 18 Jan 2020 at 15:03, ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > Hi All, > > https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT > > (Operators) infix +^§ > > multi sub infix:<+^>($a, $b --> Int:D) > > Integer bitwise XOR operator: Coerces both arguments to Int and does a > bitwise XOR (exclusive OR) operation. > > > $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = > +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' > > 01010111 > > 1101 > > > XOR > A B A xor B > 0 0 0 > 1 0 1 > 0 1 1 > 1 1 0 > > That s not what I am seeing above. > > What am I doing wrong this time? > > And who set the high bit making $z negative? > > Many thanks, > -T >
problems with xor
Hi All, https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT (Operators) infix +^§ multi sub infix:<+^>($a, $b --> Int:D) Integer bitwise XOR operator: Coerces both arguments to Int and does a bitwise XOR (exclusive OR) operation. $ p6 'my uint8 $x=0b0101_0111; my uint8 $y = 0b_; my uint8 $z = +^($x, $y ); say "0", $x.base(2); say "", $y.base(2); say $z.base(2);' 01010111 1101 XOR A B A xor B 0 0 0 1 0 1 0 1 1 1 1 0 That s not what I am seeing above. What am I doing wrong this time? And who set the high bit making $z negative? Many thanks, -T
Re: Ping JJ: string literals
>> For anyone following along that is not familiar with >> C, a BYTE in C is called a Char in C. (Causes >> some interesting conversations when UTF16 gets involved.) I don't want to make this about C, but to clarify there's no type called "BYTE" in the C language. If BYTE is defined it's system dependent and usually points to an unsigned char. >> The paragraph with the mistake in it is specifically talking about strings. That paragraph you quoted shows a message_box(Str) as the example. It's argument is undoubtedly expecting a NULL terminated string. However, your contention is about a set_foo(CArray[uint8]).. These aren't the same thing as I've already explained to you twice now. ++ With the above said, I personally _agree_ the documentation should be altered. This text preceding the example is what leads me to believe it should be: " If the C function requires the lifetime of a string to exceed the function call" This hints to me that the function call is in fact supposed to take a string. $array.elems currently shows 3 items w/ the following values: 0x46 0x4F 0x4F when I would expect, the CArray[uint8] to contain the following instead: 0x46 0x4F 0x4F 0x00 ++ In closing. if you have an example where you can get a garbage characters because of a bad example, then the example _should_ be updated. Without knowing Raku internals it's hard for me to say (I'm not a Raku dev) but I feel I'm on the right track. I've tried causing a segfault myself, but a trace of the small app always made new allocations (mmap - which zero's pages), so it's hard for me to duplicate such an error. On Fri, Jan 17, 2020 at 9:16 PM ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > For anyone following along that is not familiar with > C, a BYTE in C is called a Char in C. (Causes > some interesting conversations when UTF16 gets involved.) > > > On 2020-01-17 17:03, Paul Procacci wrote: > > >> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14. > > >> leaving off the nul is not a valid way of presenting a > > >> string to a C function. > > > > Here's the rub though Todd. Who is saying it's a string that is being > > passed? (Hint: You are) > > True. And one other place too: > > https://docs.raku.org/language/nativecall#Passing_and_returning_values > > The paragraph with the mistake in it is specifically > talking about strings. > >For strings, there is an additional encoded trait >to give some extra hints on how to do the marshaling. > >To specify how to marshal string return types, just >apply this trait to the routine itself. > >Note that a NULL string pointer can be passed by >passing the Str type object; a NULL return will >also be represented by the type object. > > At what point to you consider that they are actually speaking > about C Strings? Then they proceed to construct an > "undefined" array, not a C String. > > > > If the intention is to pass 3 bytes "FOO" starting at a given memory > > address, then it's exactly as it should be. > > That is a string literal, not a string. > > > If the intention is to pass 4 bytes "FOO\0" then yes, it's a > > documentation problem. > > Now we are talking. > > > > > The reason for this ambiguity is because the prototype accepts either-or > > of those interpretations. > > The documentation should so state. It should make > the distinction between strings and arrays (string > literals). Instead it blabs on and on about strings > and the tells you how to convert an "undefined" array. > It is clearly a mistake. > > > You can't make any definitive declaration without looking at the > > function body. > > A 'char *' doesn't automatically mean a NULL terminated string. YOU are > > making that assumption. > > It could simply accept a 3 byte character array and we're done. > > You missed my point. The structure required a > companion variable to give the array's length. > > An actual C String stands on its own. > > > > > I'm familiar with C, in fact it's my bread and butter. Quite frankly, I > > don't need the copy/pastes > > from outside sources as I know for sure that everything I've stated here > > is 100% accurate. > > That would make you the PERFECT person to clean up the documentation and > make is usable to the rest of us! > > If you are one of Raku's developers, would you please > consider taking over NativeCall's documentation page? > We need you! > > I wasn't quoting N1570 to be annoying. I am quoting it > to make sure folks know I am not blowing smoke > out my ears (I make a lot of mistakes) and that > the information is trustworthy. It is not > my "opinion". It is fact. > > > >> C can not figure out where the end of the string > > > > I don't see a string. I only see a Character Array. > > EXACTLY! That was my point. The two are different. > > How did you like the example program they guys on the > C group give me? > > And as far as the careening going: MAKE IT
Re: Ping JJ: string literals
For anyone following along that is not familiar with C, a BYTE in C is called a Char in C. (Causes some interesting conversations when UTF16 gets involved.) On 2020-01-17 17:03, Paul Procacci wrote: >> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14. >> leaving off the nul is not a valid way of presenting a >> string to a C function. Here's the rub though Todd. Who is saying it's a string that is being passed? (Hint: You are) True. And one other place too: https://docs.raku.org/language/nativecall#Passing_and_returning_values The paragraph with the mistake in it is specifically talking about strings. For strings, there is an additional encoded trait to give some extra hints on how to do the marshaling. To specify how to marshal string return types, just apply this trait to the routine itself. Note that a NULL string pointer can be passed by passing the Str type object; a NULL return will also be represented by the type object. At what point to you consider that they are actually speaking about C Strings? Then they proceed to construct an "undefined" array, not a C String. If the intention is to pass 3 bytes "FOO" starting at a given memory address, then it's exactly as it should be. That is a string literal, not a string. If the intention is to pass 4 bytes "FOO\0" then yes, it's a documentation problem. Now we are talking. The reason for this ambiguity is because the prototype accepts either-or of those interpretations. The documentation should so state. It should make the distinction between strings and arrays (string literals). Instead it blabs on and on about strings and the tells you how to convert an "undefined" array. It is clearly a mistake. You can't make any definitive declaration without looking at the function body. A 'char *' doesn't automatically mean a NULL terminated string. YOU are making that assumption. It could simply accept a 3 byte character array and we're done. You missed my point. The structure required a companion variable to give the array's length. An actual C String stands on its own. I'm familiar with C, in fact it's my bread and butter. Quite frankly, I don't need the copy/pastes from outside sources as I know for sure that everything I've stated here is 100% accurate. That would make you the PERFECT person to clean up the documentation and make is usable to the rest of us! If you are one of Raku's developers, would you please consider taking over NativeCall's documentation page? We need you! I wasn't quoting N1570 to be annoying. I am quoting it to make sure folks know I am not blowing smoke out my ears (I make a lot of mistakes) and that the information is trustworthy. It is not my "opinion". It is fact. >> C can not figure out where the end of the string I don't see a string. I only see a Character Array. EXACTLY! That was my point. The two are different. How did you like the example program they guys on the C group give me? And as far as the careening going: MAKE IT STOP! All it takes is three letters: ", 0". -T
Re: Ping JJ: string literals
>> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14.
>> leaving off the nul is not a valid way of presenting a
>> string to a C function.
Here's the rub though Todd. Who is saying it's a string that is being
passed? (Hint: You are)
If the intention is to pass 3 bytes "FOO" starting at a given memory
address, then it's exactly as it should be.
If the intention is to pass 4 bytes "FOO\0" then yes, it's a documentation
problem.
The reason for this ambiguity is because the prototype accepts either-or of
those interpretations.
You can't make any definitive declaration without looking at the function
body.
A 'char *' doesn't automatically mean a NULL terminated string. YOU are
making that assumption.
It could simply accept a 3 byte character array and we're done.
I'm familiar with C, in fact it's my bread and butter. Quite frankly, I
don't need the copy/pastes
from outside sources as I know for sure that everything I've stated here is
100% accurate.
>> C can not figure out where the end of the string
I don't see a string. I only see a Character Array.
On Fri, Jan 17, 2020 at 7:06 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> On 2020-01-17 15:34, Paul Procacci wrote:
> > Todd (and others),
> >
> > So a few things.
> >
> > 1)
> > JJ's example worked by chance. (sorry JJ).
> > It worked because it just so happens that either his OS zero filled the
> > block he was allocated by the allocator
> > or because he didn't reuse the block that was given to him initially by
> > the allocator.
> >
> > 2)
> > If you assume that the function set_foo($array) expects a NULL
> > terminated string, only then is the documentation a problem.
> > However, there's not enough information in the C prototype to make this
> > assumption. There's also no set_foo($array) function body to explore.
> >
> > # C prototype is void set_foo(const char *)
> >
> >
> > All this says is that the subroutine is receiving a pointer to memory
> > containing bytes and nothing more.
> > The body of the function _may_ simply check the first 3 bytes. This is
> > up to the reader to ascertain.
> >
> > 3) As for a documentation update, I'm unsure if it's required. The
> > example is not only perfectly valid raku, it's also perfectly valid C.
>
> Actually, it is not perfectly okay with C. Let me state
> my case:
>
> Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14.
> leaving off the nul is not a valid way of presenting a
> string to a C function.
>
> C can not figure out where the end of the string is
> on its own without the nul. It will careen until it
> find a nul. Even further if the string is UTF16 and
> is looking for a double nul (0x);
>
> Now if you want to do a "String Literal", you can
> leave the nul off. But it required that you inform
> to other end as to the String Literal's length. And
> a "String Literal" IS NOT a C string.
>
> "String Literal's" are covered by N1570 6.7.9,p14
>
> An example of a string literal can be found at:
>
>
> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
>
> "const BYTE *lpData" points to the String Leteral, and
>
> "DWORD cbData" contains the length of the string literal
>
> C Strings and String Literals are two vastly different things.
>
> In that same example:
>
> "LPCWSTR lpValueName" points to a C String that must
> be nul terminated. Note that there is no companion
> variable stating its length
>
>
> > Perhaps something could be added to remove whatever ambiguity you
> > perceive, but you argument stems from something that isn't necessarily
> > true in this example
> > and that's the function set_foo($array) expects a NULL terminated string.
> >
> > ~Paul
>
> Hi Paul,
>
> This is the example I previously posted of careening
> that drove me crazy trying to troubleshoot. The C guys
> told me it was not a convincing example.
>
> https://ibb.co/tHy7ZQM
>
> The C Spec N1570, 5.2.1, p2 is very clear:
>
> A byte with
> all bits set to 0, called the
> null character, shall exist in the basic
> execution character set; it
> is used to
> terminate a character string.
>
>
> And not including it causes all kinds of consternation,
> as I found out the hard way.
>
> -T
>
--
__
:(){ :|:& };:
Re: GIT PR Help
On 2020-01-17 16:02, Trey Harris wrote: On Fri, Jan 17, 2020 at 17:35 ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: Hi Trey, I wanted to add an example to https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT Do I Git the entire documentation project to do so? Can I jsut Git that page? If so, where do I find it to Git? And when I ask for an evaluation, do they have to dig through the entire project to find my additions? You described yourself as a sysadmin at one point, so as a former sysadmin, I may have been assuming a certain basis of shared knowledge we do not have. If you simply weren’t familiar with Git, I’d have some suggestions for ways to fake it. But if you’re not familiar with the concepts of a unified diff, how patchfiles are generated and applied, or commits as tree deltas over time, then I’d suggest you simply post your suggested example in a Github Issue and explain that you don’t understand Git well enough to do this yourself. Hi Trey, You can drive a truck through the definition of a Sys Admin. I do I.T. support for small businesses. I get called all kinds of titles. (I actually find it sweet that I get called a Nerd a lot. They mean it with affection.) An actual title I do have is Bachelor of Science in Computer and Electronic Engineering. So, I am technically an "Engineer". Never got the PE (professional engineer) stamp from the State though, as I do not need it for what I do. https://github.com/Raku/doc/issues Seems like an excellent place to post suggestions until I get to the point were I understand Pull Requests better. Thank you! :-) -T Tom wrote me off line that he is working on a How To paper for Git and Pull. That should do the trick!
Re: Ping JJ: string literals
On 2020-01-17 15:34, Paul Procacci wrote: Todd (and others), So a few things. 1) JJ's example worked by chance. (sorry JJ). It worked because it just so happens that either his OS zero filled the block he was allocated by the allocator or because he didn't reuse the block that was given to him initially by the allocator. 2) If you assume that the function set_foo($array) expects a NULL terminated string, only then is the documentation a problem. However, there's not enough information in the C prototype to make this assumption. There's also no set_foo($array) function body to explore. # C prototype is void set_foo(const char *) All this says is that the subroutine is receiving a pointer to memory containing bytes and nothing more. The body of the function _may_ simply check the first 3 bytes. This is up to the reader to ascertain. 3) As for a documentation update, I'm unsure if it's required. The example is not only perfectly valid raku, it's also perfectly valid C. Actually, it is not perfectly okay with C. Let me state my case: Take a peak at N1570, 5.2.1p2, 7.1.1 and 6.7.9,p14. leaving off the nul is not a valid way of presenting a string to a C function. C can not figure out where the end of the string is on its own without the nul. It will careen until it find a nul. Even further if the string is UTF16 and is looking for a double nul (0x); Now if you want to do a "String Literal", you can leave the nul off. But it required that you inform to other end as to the String Literal's length. And a "String Literal" IS NOT a C string. "String Literal's" are covered by N1570 6.7.9,p14 An example of a string literal can be found at: https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw "const BYTE *lpData" points to the String Leteral, and "DWORD cbData" contains the length of the string literal C Strings and String Literals are two vastly different things. In that same example: "LPCWSTR lpValueName" points to a C String that must be nul terminated. Note that there is no companion variable stating its length Perhaps something could be added to remove whatever ambiguity you perceive, but you argument stems from something that isn't necessarily true in this example and that's the function set_foo($array) expects a NULL terminated string. ~Paul Hi Paul, This is the example I previously posted of careening that drove me crazy trying to troubleshoot. The C guys told me it was not a convincing example. https://ibb.co/tHy7ZQM The C Spec N1570, 5.2.1, p2 is very clear: A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string. And not including it causes all kinds of consternation, as I found out the hard way. -T
Re: GIT PR Help
On Fri, Jan 17, 2020 at 17:35 ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > Hi Trey, > > I wanted to add an example to > > https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT > > Do I Git the entire documentation project to do so? > Can I jsut Git that page? If so, where do I find > it to Git? > > And when I ask for an evaluation, do they have to dig > through the entire project to find my additions? You described yourself as a sysadmin at one point, so as a former sysadmin, I may have been assuming a certain basis of shared knowledge we do not have. If you simply weren’t familiar with Git, I’d have some suggestions for ways to fake it. But if you’re not familiar with the concepts of a unified diff, how patchfiles are generated and applied, or commits as tree deltas over time, then I’d suggest you simply post your suggested example in a Github Issue and explain that you don’t understand Git well enough to do this yourself.
Re: Ping JJ: string literals
Todd (and others),
So a few things.
1)
JJ's example worked by chance. (sorry JJ).
It worked because it just so happens that either his OS zero filled the
block he was allocated by the allocator
or because he didn't reuse the block that was given to him initially by the
allocator.
2)
If you assume that the function set_foo($array) expects a NULL terminated
string, only then is the documentation a problem.
However, there's not enough information in the C prototype to make this
assumption. There's also no set_foo($array) function body to explore.
# C prototype is void set_foo(const char *)
All this says is that the subroutine is receiving a pointer to memory
containing bytes and nothing more.
The body of the function _may_ simply check the first 3 bytes. This is up
to the reader to ascertain.
3) As for a documentation update, I'm unsure if it's required. The example
is not only perfectly valid raku, it's also perfectly valid C.
Perhaps something could be added to remove whatever ambiguity you perceive,
but you argument stems from something that isn't necessarily true in this
example
and that's the function set_foo($array) expects a NULL terminated string.
~Paul
On Fri, Jan 17, 2020 at 5:29 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> Hi JJ,
>
> Please be my hero.
>
> I won't call you any goofy names out of
> affection and friendship, as others will get
> their nickers in a twist.
>
> This is from a previous conversation we had concerning
> the mistake in
>
> https://docs.raku.org/language/nativecall#index-entry-nativecall
>
> my $string = "FOO";
> ...
> my $array = CArray[uint8].new($string.encode.list);
>
>
> Todd:
> By the way, "C String" REQUIRES a nul at the end:
> an error in the NativeCall documentation.
>
> JJ:
> No, it does not. And even if it did, it should better
> go to the C, not Raku, documentation
>
>
> And that would be a "String Literal", which is NOT
> a C String. And C's documentation is precise and
> clear (n1570). It is not their problem. It
> is a mistake in NativeCall's documentation.
>
> Without the nul at the end, the string is considered
> "undefined".
>
> The C guys have been helping me with definitions. Chapter and
> verse would be :
>
> 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
> 7.1.1 Definitions of terms
> 6.7.9,p14 Semantics
>
> Here is your String Literal, which you are confusing
> with a c string:
>
> 6.7.9,p14 states:
>
> An array of character type may be initialized by a
> character string literal or UTF−8 string literal,
> optionally enclosed in braces. Successive bytes
> of the string literal (including the terminating
> null character if there is room or if the array
> is of unknown size) initialize the elements of
> the array.
>
> So there is the unnecessary nul you speak of, except,
> again, it is not a C String. So you do have a
> somewhat of a point, although not a good one as
> it will throw those trying to use the docs into
> a state of confusion wondering what is going wrong,
> as it did me.
>
> It about killed me to figure it our myself. I
> don't want others to go through the same pain
> over a simple mistake in the documentation.
>
> Now the C guys told me that the reason why I am not
> getting anywhere with you is that I provided a bad
> example. They proceeded to give me an example
> that precisely shows the careening make by
> the mistake in the documentation:
>
>
> An example of an unterminated C string:
>
> On 2020-01-17 13:21, Bart wrote:
> >
> >
> > #include
> >
> > void foo(const char *s)
> > {
> > for (int i=0; i<10; ++i)
> > printf("%d ",*s++);
> > puts("");
> >
> > }
> >
> > int main(void)
> > {
> > char str[3] = "FOO";
> > foo(str);
> > }
> >
>
>
> To compile:
> gcc -o t2 t2.c
>
> To Run
> t2
>
>
> > This prints the 3 characters codes of F,O,O in the string, plus 7
> > bytes that follow. Results on various compilers are as follows:
> >
> > bcc: 70 79 79 0 0 0 0 0 0 0
> > tcc: 70 79 79 80 -1 18 0 0 0 0
> > gcc -O0: 70 79 79 112 -14 48 0 0 0 0
> > gcc -O3: 70 79 79 2 0 0 0 0 0 0
> > lcc: 70 79 79 0 0 0 0 0 0 0
> > dmc: 70 79 79 0 -120 -1 24 0 25 33
> > clang -O0: 70 79 79 16 6 64 0 0 0 0
> > clang -O2: 70 79 79 0 48 -120 73 6 -19 127
> > msvc:70 79 79 -29 -9 127 0 0 0 0
> >
> > The 70, 79, 79 are the F, O and O codes. When those 3 happen to
> > be followed by 0, then it will appear to work.
> >
> > That is 4 out of 9, but the other 5 won't work. What follows
> > after FOO is undefined and could be anything, although a random 0 is
> common.
> >
>
> JJ! He ran it through NINE C compilers! The careening
> is OBVIOUS!
>
> And this mistake is very easy to fix:
>
> Change
> my $array =
Re: GIT PR Help
On 2020-01-17 13:47, Trey Harris wrote: On Fri, Jan 17, 2020 at 15:44 ToddAndMargo via perl6-users mailto:perl6-users@perl.org>> wrote: On 2020-01-17 12:20, Trey Harris wrote: > If the issue is that you aren’t comfortable enough with Git¹, I assume > as part of the basic toolkit of a sysadmin you know how to generate a > unified diff patchfile (with `diff -ruN` or equivalent)? > > If so, if you generate one and upload it attached to a GitHub issue, we > can figure out how to turn it into a PR rather trivially (and if I’m the > first to pick it up, I’ll include step-by-step instructions on how to do > it as a Git PR in the future). Now I am confused. Exactly what is going on with a PR? A “PR” is a “pull request”—in Git terminology, a request to apply a patch. It formalizes and standardizes the process that existed on many FOSS project dev mailing lists (most notable the Linux kernel’s) that consisted of someone emailing the list with a unified patchfile, someone else with the right to directly commit replying with requested changes, a new patchfile being generated, and so on until finally the changes in the patch were judged okay and the patch was applied. A plain unadorned Git PR flow is nothing more than this in a very standardized format, with tools to do the fiddly bits. When using GitHub, the tools have been melded to ones allowing for line-by-line code comments and approvals, visual side-by-side diffing, etc. What I am after is to add an example to a document page. Is there any special thing about this other than just asked for it? It sounds like I download my own copy of the page (with git), then make the alterations, then request others evaluate it? That’s all. You edit the file in your working directory where you want something changed, commit those changes locally to your personal Git repo clone, and submit it. It’s like modifying a wiki except that the changes aren’t immediate. The very easiest way (IMHO) to do this for a GitHub-hosted project like this is to navigate to the official repo on GitHub (here, https://github.com/raku/doc) while logged in to your GitHub account, and click “fork”. So you’ll have a toddandmargo/doc instead of raku/doc that forked from raku/doc at the moment you forked it. Then make your changes either of two ways: 1. More flexible but requiring more Git knowledge: clone your fork with its “remote origin” and “upstream” set such that you can run the “git pull” command to pull changes to the original docs repo through your fork and into your local working copy. The GitHub web UI gives instructions right there by the “clone” button on your fork’s page on how to do this. Then you make your changes locally, commit them locally, and push them up. When you visit your fork on the webpage (at, e.g., https://github.com/toddandmargo/docs) it will notice you just did this and offer a friendly notification complete with green button to turn your changes into a PR right there and take care of the fiddly bits. 2. Less flexible but easier, especially for small changes: use the GitHub web UI editing tools to just edit the files inline in your fork (at, e.g., https://github.com/toddandmargo/docs). GitHub will automatically generate the commits and again display a friendly prompt to create a pull request when you’re ready. Trey Hi Trey, I wanted to add an example to https://docs.raku.org/routine/+$CIRCUMFLEX_ACCENT Do I Git the entire documentation project to do so? Can I jsut Git that page? If so, where do I find it to Git? And when I ask for an evaluation, do they have to dig through the entire project to find my additions? I am confused, -T -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Ping JJ: string literals
Hi JJ,
Please be my hero.
I won't call you any goofy names out of
affection and friendship, as others will get
their nickers in a twist.
This is from a previous conversation we had concerning
the mistake in
https://docs.raku.org/language/nativecall#index-entry-nativecall
my $string = "FOO";
...
my $array = CArray[uint8].new($string.encode.list);
Todd:
By the way, "C String" REQUIRES a nul at the end:
an error in the NativeCall documentation.
JJ:
No, it does not. And even if it did, it should better
go to the C, not Raku, documentation
And that would be a "String Literal", which is NOT
a C String. And C's documentation is precise and
clear (n1570). It is not their problem. It
is a mistake in NativeCall's documentation.
Without the nul at the end, the string is considered
"undefined".
The C guys have been helping me with definitions. Chapter and
verse would be :
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
7.1.1 Definitions of terms
6.7.9,p14 Semantics
Here is your String Literal, which you are confusing
with a c string:
6.7.9,p14 states:
An array of character type may be initialized by a
character string literal or UTF−8 string literal,
optionally enclosed in braces. Successive bytes
of the string literal (including the terminating
null character if there is room or if the array
is of unknown size) initialize the elements of
the array.
So there is the unnecessary nul you speak of, except,
again, it is not a C String. So you do have a
somewhat of a point, although not a good one as
it will throw those trying to use the docs into
a state of confusion wondering what is going wrong,
as it did me.
It about killed me to figure it our myself. I
don't want others to go through the same pain
over a simple mistake in the documentation.
Now the C guys told me that the reason why I am not
getting anywhere with you is that I provided a bad
example. They proceeded to give me an example
that precisely shows the careening make by
the mistake in the documentation:
An example of an unterminated C string:
On 2020-01-17 13:21, Bart wrote:
#include
void foo(const char *s)
{
for (int i=0; i<10; ++i)
printf("%d ",*s++);
puts("");
}
int main(void)
{
char str[3] = "FOO";
foo(str);
}
To compile:
gcc -o t2 t2.c
To Run
t2
This prints the 3 characters codes of F,O,O in the string, plus 7
bytes that follow. Results on various compilers are as follows:
bcc: 70 79 79 0 0 0 0 0 0 0
tcc: 70 79 79 80 -1 18 0 0 0 0
gcc -O0: 70 79 79 112 -14 48 0 0 0 0
gcc -O3: 70 79 79 2 0 0 0 0 0 0
lcc: 70 79 79 0 0 0 0 0 0 0
dmc: 70 79 79 0 -120 -1 24 0 25 33
clang -O0: 70 79 79 16 6 64 0 0 0 0
clang -O2: 70 79 79 0 48 -120 73 6 -19 127
msvc:70 79 79 -29 -9 127 0 0 0 0
The 70, 79, 79 are the F, O and O codes. When those 3 happen to
be followed by 0, then it will appear to work.
That is 4 out of 9, but the other 5 won't work. What follows
after FOO is undefined and could be anything, although a random 0 is common.
JJ! He ran it through NINE C compilers! The careening
is OBVIOUS!
And this mistake is very easy to fix:
Change
my $array = CArray[uint8].new($string.encode.list);
to
my $array = CArray[uint8].new($string.encode.list, 0);
THREE characters `, 0` and it is fixed! And you are
are finally conforming to n1570. And you will be
my ever living hero! (Watch some take offense to that!)
Have I still not convinced you? THREE CHARACTERS
Sorry for being such a pest about this. It about killed
me to figure out.
Please be my hero.
-T
Retrievers are better looking than Labs. (I can't
wait for the hate mail over that!)
Re: GIT PR Help
On Fri, Jan 17, 2020 at 15:44 ToddAndMargo via perl6-users < perl6-users@perl.org> wrote: > On 2020-01-17 12:20, Trey Harris wrote: > > If the issue is that you aren’t comfortable enough with Git¹, I assume > > as part of the basic toolkit of a sysadmin you know how to generate a > > unified diff patchfile (with `diff -ruN` or equivalent)? > > > > If so, if you generate one and upload it attached to a GitHub issue, we > > can figure out how to turn it into a PR rather trivially (and if I’m the > > first to pick it up, I’ll include step-by-step instructions on how to do > > it as a Git PR in the future). > > Now I am confused. Exactly what is going on with a PR? A “PR” is a “pull request”—in Git terminology, a request to apply a patch. It formalizes and standardizes the process that existed on many FOSS project dev mailing lists (most notable the Linux kernel’s) that consisted of someone emailing the list with a unified patchfile, someone else with the right to directly commit replying with requested changes, a new patchfile being generated, and so on until finally the changes in the patch were judged okay and the patch was applied. A plain unadorned Git PR flow is nothing more than this in a very standardized format, with tools to do the fiddly bits. When using GitHub, the tools have been melded to ones allowing for line-by-line code comments and approvals, visual side-by-side diffing, etc. > What I am after is to add an example to a document page. > Is there any special thing about this other than just > asked for it? It sounds like I download my own copy > of the page (with git), then make the alterations, > then request others evaluate it? That’s all. You edit the file in your working directory where you want something changed, commit those changes locally to your personal Git repo clone, and submit it. It’s like modifying a wiki except that the changes aren’t immediate. The very easiest way (IMHO) to do this for a GitHub-hosted project like this is to navigate to the official repo on GitHub (here, https://github.com/raku/doc) while logged in to your GitHub account, and click “fork”. So you’ll have a toddandmargo/doc instead of raku/doc that forked from raku/doc at the moment you forked it. Then make your changes either of two ways: 1. More flexible but requiring more Git knowledge: clone your fork with its “remote origin” and “upstream” set such that you can run the “git pull” command to pull changes to the original docs repo through your fork and into your local working copy. The GitHub web UI gives instructions right there by the “clone” button on your fork’s page on how to do this. Then you make your changes locally, commit them locally, and push them up. When you visit your fork on the webpage (at, e.g., https://github.com/toddandmargo/docs) it will notice you just did this and offer a friendly notification complete with green button to turn your changes into a PR right there and take care of the fiddly bits. 2. Less flexible but easier, especially for small changes: use the GitHub web UI editing tools to just edit the files inline in your fork (at, e.g., https://github.com/toddandmargo/docs). GitHub will automatically generate the commits and again display a friendly prompt to create a pull request when you’re ready. Trey
Re: GIT PR Help
A 17 de janeiro de 2020 21:44:00 CET, ToddAndMargo via perl6-users escreveu: >On 2020-01-17 12:20, Trey Harris wrote: >> If the issue is that you aren’t comfortable enough with Git¹, I assume >> as part of the basic toolkit of a sysadmin you know how to generate a >> unified diff patchfile (with `diff -ruN` or equivalent)? >> >> If so, if you generate one and upload it attached to a GitHub issue, we >> can figure out how to turn it into a PR rather trivially (and if I’m the >> first to pick it up, I’ll include step-by-step instructions on how to do >> it as a Git PR in the future). > >Now I am confused. Exactly what is going on with a PR? > >What I am after is to add an example to a document page. >Is there any special thing about this other than just >asked for it? It sounds like I download my own copy >of the page (with git), then make the alterations, >then request others evaluate it? > >Your in confusion, >-T Offlist Git is a distributed version control system. This means that you create copies of the original (upstream) repo (hence the distributed part). This is a very simplified explanation: So you do your changes and commit on your repo. Since you want your changes to go to upstream, you need to create a pr (pull request). Github helps in this, which means that you push your changes to your repo in github (assuming that you forked to your account in github), also known as origin, and on github a link will appear to create a pull request. If you click on that link, you will be redirected to the create pull request page, where you can see your changes. Then the pr needs to be aproved to be merged into upstream, you might get some comments with changes you need to do and so. You then just commit the new changes and push them to your repo in git and the pr is updated. This is just one of many workflows possible with git. Let me know if you have questions Regards, David -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: GIT PR Help
On 2020-01-17 12:20, Trey Harris wrote: If the issue is that you aren’t comfortable enough with Git¹, I assume as part of the basic toolkit of a sysadmin you know how to generate a unified diff patchfile (with `diff -ruN` or equivalent)? If so, if you generate one and upload it attached to a GitHub issue, we can figure out how to turn it into a PR rather trivially (and if I’m the first to pick it up, I’ll include step-by-step instructions on how to do it as a Git PR in the future). Now I am confused. Exactly what is going on with a PR? What I am after is to add an example to a document page. Is there any special thing about this other than just asked for it? It sounds like I download my own copy of the page (with git), then make the alterations, then request others evaluate it? Your in confusion, -T
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
If the issue is that you aren’t comfortable enough with Git¹, I assume as part of the basic toolkit of a sysadmin you know how to generate a unified diff patchfile (with `diff -ruN` or equivalent)? If so, if you generate one and upload it attached to a GitHub issue, we can figure out how to turn it into a PR rather trivially (and if I’m the first to pick it up, I’ll include step-by-step instructions on how to do it as a Git PR in the future). — ¹ Though in searching through the email logs to see what familiarity you’d shown with Git in the past, it seems like this is something that’s held you back enough that learning it would likely pay large dividends in the future. On Fri, Jan 17, 2020 at 14:56 Tom Browder wrote: > On Fri, Jan 17, 2020 at 1:44 PM ToddAndMargo via perl6-users > wrote: > ... > > Was this what you were referring to? > > > > https://github.com/Raku/doc/blob/master/CONTRIBUTING.md > > No, check this link: > > > https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request > > -Tom >
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-17 11:55, Tom Browder wrote: On Fri, Jan 17, 2020 at 1:44 PM ToddAndMargo via perl6-users wrote: ... Was this what you were referring to? https://github.com/Raku/doc/blob/master/CONTRIBUTING.md No, check this link: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request -Tom I have got some reading to do. Thank you!
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On Fri, Jan 17, 2020 at 1:44 PM ToddAndMargo via perl6-users wrote: ... > Was this what you were referring to? > > https://github.com/Raku/doc/blob/master/CONTRIBUTING.md No, check this link: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request -Tom
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-17 11:43, ToddAndMargo via perl6-users wrote: On 2020-01-17 06:58, Tom Browder wrote: On Fri, Jan 17, 2020 at 06:06 Todd Chester via perl6-users mailto:perl6-users@perl.org>> wrote: On 2020-01-17 00:12, Veesh Goldman wrote: > he's finally looked into making pull requests. Do you have a link to the pull requests for the documentation? I'd like to add some examples to a few pages. Todd, I don't think that link will help until you understand what actually you need to contribute a PR. As I said before, I'll be happy to give you a step-by-step recipe for creating a PR for the docs after you decide on a clean directory to use for cloning the doc repository. I think you said you are too busy at the moment. I am frighteningly busy at the moment. But, a little creative helps with the busy. I was thinking of putting is a pull for an example on one of the bitwise pages. If you can't find the time now, okay. In any event, you can look at the Github help section and find out more about PRs. Better yet, go to the Git home page and check out their documentation (which includes videos). Website is: https://git-scm.com -Tom I checked that link, but could only find a reference to https://git-scm.com/docs/git-request-pull Maybe I do not understand what a pull request is. I tough it was just writing a respectful letter like you do on Bugzillas. I am looking at current pull requests, and that seems to also be the case. Maybe you should send me over your How To before I stick my foot in my mouth, again. -T Was this what you were referring to? https://github.com/Raku/doc/blob/master/CONTRIBUTING.md
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-17 06:58, Tom Browder wrote: On Fri, Jan 17, 2020 at 06:06 Todd Chester via perl6-users mailto:perl6-users@perl.org>> wrote: On 2020-01-17 00:12, Veesh Goldman wrote: > he's finally looked into making pull requests. Do you have a link to the pull requests for the documentation? I'd like to add some examples to a few pages. Todd, I don't think that link will help until you understand what actually you need to contribute a PR. As I said before, I'll be happy to give you a step-by-step recipe for creating a PR for the docs after you decide on a clean directory to use for cloning the doc repository. I think you said you are too busy at the moment. I am frighteningly busy at the moment. But, a little creative helps with the busy. I was thinking of putting is a pull for an example on one of the bitwise pages. If you can't find the time now, okay. In any event, you can look at the Github help section and find out more about PRs. Better yet, go to the Git home page and check out their documentation (which includes videos). Website is: https://git-scm.com -Tom I checked that link, but could only find a reference to https://git-scm.com/docs/git-request-pull Maybe I do not understand what a pull request is. I tough it was just writing a respectful letter like you do on Bugzillas. I am looking at current pull requests, and that seems to also be the case. Maybe you should send me over your How To before I stick my foot in my mouth, again. -T -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-17 06:15, Shlomi Fish wrote: Hi Todd, On Fri, 17 Jan 2020 04:06:10 -0800 Todd Chester via perl6-users wrote: On 2020-01-17 00:12, Veesh Goldman wrote: he's finally looked into making pull requests. Do you have a link to the pull requests for the documentation? I'd like to add some examples to a few pages. See https://github.com/Raku/doc/pulls . Good luck! Thank you! For some reason I have all kinds of trouble finding what I want on GIT, probably my google skills.
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On Fri, Jan 17, 2020 at 06:06 Todd Chester via perl6-users < perl6-users@perl.org> wrote: > > > On 2020-01-17 00:12, Veesh Goldman wrote: > > he's finally looked into making pull requests. > > Do you have a link to the pull requests for > the documentation? I'd like to add some examples > to a few pages. Todd, I don't think that link will help until you understand what actually you need to contribute a PR. As I said before, I'll be happy to give you a step-by-step recipe for creating a PR for the docs after you decide on a clean directory to use for cloning the doc repository. I think you said you are too busy at the moment. If you can't find the time now, okay. In any event, you can look at the Github help section and find out more about PRs. Better yet, go to the Git home page and check out their documentation (which includes videos). Website is: https://git-scm.com -Tom
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
Hi Todd, On Fri, 17 Jan 2020 04:06:10 -0800 Todd Chester via perl6-users wrote: > On 2020-01-17 00:12, Veesh Goldman wrote: > > he's finally looked into making pull requests. > > Do you have a link to the pull requests for > the documentation? I'd like to add some examples > to a few pages. See https://github.com/Raku/doc/pulls . Good luck! -- Shlomi Fish https://www.shlomifish.org/ https://github.com/shlomif/shlomif-computer-settings/ - my dotfiles There’s no point in keeping an idea to yourself since there’s a 10 to 1 chance that somebody already has it and will share it before you. — http://www.shlomifish.org/humour.html Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-17 00:12, Veesh Goldman wrote: he's finally looked into making pull requests. Do you have a link to the pull requests for the documentation? I'd like to add some examples to a few pages.
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
I just want to point out in Todd's credit that he both admitted that he doesn't know how to use github, and that he's finally looked into making pull requests. On Fri, Jan 17, 2020 at 1:21 AM Elizabeth Mattijsen wrote: > > On 16 Jan 2020, at 21:13, ToddAndMargo via perl6-users < > perl6-users@perl.org> wrote: > > On 2020-01-16 12:09, Elizabeth Mattijsen wrote: > >>> On 16 Jan 2020, at 20:29, Darren Duncan > wrote: > >>> On 2020-01-16 3:09 a.m., Elizabeth Mattijsen wrote: > I wonder if this is how you treat your family as well. If you do, > then I feel sorry for your family. And wouldn't be surprised if they > abandoned you. > >>> That is unnecessarily harsh and uncalled for Liz, the last sentence > particularly. > >> I'll give you that it may have been unnecessary harsh. For which I > apologize. > >> Liz > > > > Thank you Liz. Accepted. > > > > Can we be friends again? > > We were never friends. Online acquaintance at best. I guess in the > current polarized United States, anybody who is not your enemy, is your > friend. It doesn't work like that for me. > > > You might earn some respect with me. But I doubt it. > > > Liz
