tl;dr: is this a Rakudo issue? ooh a puzzle 😀 why do 'ff' and 'fff' give different results in this case? The start & end are disjoint, the $++ should only run when the string test is true, so I expect 'ff' and 'fff' to behave the same also.
Golfing a little $ raku -e 'my @input=qw<nope + B C D - 1 - no + E F - 2 3 - never never + G - 4 5 - hide>; \ say "With ff: ",@input.grep({($_ eq "+" && $++ < 2) ff ($_ eq "-" && $++ < 2)}); \ say "With fff: ",@input.grep({($_ eq "+" && $++ < 2) fff ($_ eq "-" && $++ < 2)});' With ff: (+ B C D - + E F - 2 3 - never never + G - 4 5 - hide) With fff: (+ B C D - + E F -) With both of these, the flip-flop turns on with the first '+' and turns off with the first '-' With both of these, the 2nd '+' turns on the flip-flop. WIth 'ff', the flip-flop never turns off, with 'fff' the flip-flop turns off when it encounters the next '-' I wonder... let's have the end of the flip-flop say every time it runs raku -e 'my @input=qw<nope + B C D - ?? - no + E F - !! ## - never never + G - %% && - hide>; \ say "With ff: ";say @input.grep({($_ eq "+" && $++ < 2) ff ("checking $_".say && $_ eq "-" && say "increment to " ~ ++$ )}); \ say "With fff:";say @input.grep({($_ eq "+" && $++ < 2) fff ("checking $_".say && $_ eq "-" && say "increment to " ~ ++$ )});' With ff: checking nope checking + checking B checking C checking D checking - increment to 1 checking ?? checking - increment to 2 checking no checking + checking E checking F checking - increment to 3 checking !! checking ## checking - increment to 4 checking never checking never checking + checking G checking - increment to 5 checking %% checking && checking - increment to 6 checking hide (+ B C D - + E F -) With fff: checking B checking C checking D checking - increment to 1 checking E checking F checking - increment to 2 (+ B C D - + E F -) Hey gurus, why is the end check in 'ff' running so much more often than the end check of 'fff' ? ps. I had many weird errors, due to having "rake" installed, and having something autocorrect my "raku" command-line to "rake"!!! -y On Sat, Aug 1, 2020 at 10:06 PM William Michels <w...@caa.columbia.edu> wrote: > Hi Yary, Nice code! > > The general approach of using an anonymous counter is useful to me. Below > are examples when I only want to recover the first one or two blocks of > text starting with "Start" and ending with "Mark" (nota bene: I took your > example text and deleted the blank lines): > > user@book:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) fff ($_ eq > "Mark" && $++ < 1);' yary_ff_example2.txt > Start > hi print me > yes! > Mark > user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) ff ($_ eq > "Mark" && $++ < 1);' yary_ff_example2.txt > Start > hi print me > yes! > Mark > user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) fff ($_ eq > "Mark" && $++ < 2);' yary_ff_example2.txt > Start > hi print me > yes! > Mark > Start > We're back! > Mark > user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) ff ($_ eq > "Mark" && $++ < 2);' yary_ff_example2.txt > Start > hi print me > yes! > Mark > Start > We're back! > Mark > Still here! > Start > haha that Start does nothing > going to end it now > Mark > !bye bye don't see me! > user@mbook:~$ > > I guess I have to say--I'm still a little surprised by the last result > using the "ff" infix operator. I'd appreciate knowing why "ff" and "fff" > behave differently in the last two examples, since the beginning marker > doesn't look anything like the end marker (suggesting they should act > identically). Also, is there a simpler way to write the conditional? > > Thx, Bill. > > > > On Sat, Aug 1, 2020 at 4:04 PM yary <not....@gmail.com> wrote: > > > > This made me want to try a contrived puzzle, use 'fff' to show things > between a "start" and 2nd "mark" line. That is, print any line below not > marked with "!" at the start > > > > $ cat example.txt > > > > !ignore me > > > > Start > > > > hi print me > > > > yes! > > > > Mark > > > > still print me > > > > Mark > > > > !ignore this line > > > > !this line too > > > > Start > > > > We're back! > > > > Mark > > > > Still here! > > > > Start > > > > haha that Start does nothing > > > > going to end it now > > > > Mark > > > > !bye bye don't see me! > > > > > > Let's see...ooh that was easy!! > > > > raku -ne '.say if "Start" ff ($_ eq "Mark" && ++$ %% 2)' example.txt > > > > > > That increments the anonymous state variable $ and then checks if it is > divisible by 2, so that only every 2nd Mark returns True > > > > Don't know if I'll ever need it, fun to have it. > > > > -y > > > > > > On Tue, Jul 28, 2020 at 7:09 PM Brad Gilbert <b2gi...@gmail.com> wrote: > >> > >> A regex doesn't have to match the entire string. > >> > >> 'abcd' ~~ / bc / > >> # ï½¢bcï½£ > >> > >> A string has to match exactly with the smart-match. (`ff` and `fff` do > smart-match) > >> > >> 'abcd' ~~ 'bc' # False > >> 'abcd' ~~ 'abcd' # True > >> > >> A string inside of a regex only makes that a single atom, it does not > make it match like just a string. > >> > >> 'abcd' ~~ / 'bc' / > >> # ï½¢bcï½£ > >> > >> 'aBaBaB' ~~ / aB+ / > >> ï½¢aBï½£ > >> > >> 'aBaBaB' ~~ / "aB"+ / > >> ï½¢aBaBaBï½£ > >> > >> In fact a string inside of a regex doesn't do much more than square > brackets. > >> > >> 'aBaBaB' ~~ / [aB]+ / > >> ï½¢aBaBaBï½£ > >> > >> If you want the regex to match fully, add a beginning of string and end > of string marker. > >> > >> 'abcd' ~~ / ^ bc $ / > >> # Nil > >> > >> 'abcd' ~~ / ^ abcd $ / > >> # ï½¢abcdï½£ > >> > >> --- > >> > >> Since `ff` can begin and end at the same time, the following is turning > on and off at almost every iteration of the loop after it starts. > >> > >> $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off > ]}/ ;' startling.txt > >> on star > >> on off start > >> on off startl > >> on off startli > >> on off startlin > >> on off startling > >> > >> On Tue, Jul 28, 2020 at 1:43 PM William Michels <w...@caa.columbia.edu> > wrote: > >>> > >>> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix > >>> operators in Raku to me! > >>> > >>> I have to admit that I'm still fuzzy on the particulars between "ff" > >>> and "fff", since I am not familiar with the sed function. I can > >>> certainly understand how useful these functions could be to 'pull out > >>> all PGP signatures' from a file (which was the Perl5 example given in > >>> the Oracle Linux Blog). So I can now pull out the html "head" section > >>> from the page _ https://raku.org/fun/ _ (saved locally as file > >>> "fun.txt") using the following Raku code: > >>> > >>> user@mbook:~$ raku -ne '.put if Q[<head>] ff Q[</head>]' fun.txt > >>> <head> > >>> <meta charset="utf-8"> > >>> <meta http-equiv="X-UA-Compatible" content="IE=edge"> > >>> <meta name="viewport" content="width=device-width, > initial-scale=1"> > >>> <title>Raku is optimized for fun!</title> > >>> > >>> > >>> <link href="/favicon.ico" rel="shortcut icon" type="image/x-icon"> > >>> <link href="/bootstrap/css/bootstrap.min.css" rel="stylesheet"> > >>> <link href="/bootstrap/css/bootstrap-theme.min.css" > rel="stylesheet"> > >>> <link href="/style.css?v=1" rel="stylesheet"> > >>> > >>> </head> > >>> user@mbook:~$ > >>> > >>> What I'm less clear on is how the code below is functioning. I first > >>> print out file named "startling.txt" with 'cat': it's supposed to > >>> stand in for a text delimited linewise by "header 1", "header 2", etc. > >>> After the 'cat' example, I show three examples with Perl(v5.26.3) and > >>> three examples with Raku(2020.06), generally comparing literal vs > >>> regex arguments. > >>> > >>> The first two Perl5 examples returns nothing; the third Perl5 example > >>> returns everything after the "star" line. For the Raku code, the > >>> 'DWIMmiest' output below is the first Raku example, which returns two > >>> lines, "star" and "start". This is what I expected/desired. But I'm > >>> not really understanding what's happening with the other 2 Raku > >>> examples (which return everything after the "star" line): > >>> > >>> user@mbook:~$ cat startling.txt > >>> s > >>> st > >>> sta > >>> star > >>> start > >>> startl > >>> startli > >>> startlin > >>> startling > >>> > >>> user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt > >>> user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' > startling.txt > >>> user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt > >>> star > >>> start > >>> startl > >>> startli > >>> startlin > >>> startling > >>> user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt > >>> star > >>> start > >>> user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt > >>> star > >>> start > >>> startl > >>> startli > >>> startlin > >>> startling > >>> user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt > >>> star > >>> start > >>> startl > >>> startli > >>> startlin > >>> startling > >>> user@mbook:~$ > >>> > >>> I'm all in favor of improving the "ff" and "fff" functions in Raku > >>> over their Perl5 counterparts, but I'm hoping to gain a better > >>> (mnemonic?) way of remembering the expected return values with literal > >>> vs regex arguments. > >>> > >>> Any assistance appreciated, Bill. > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Sun, Jul 26, 2020 at 10:04 AM Larry Wall <la...@wall.org> wrote: > >>> > > >>> > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote: > >>> > : In the above two cases ff and fff would behave identically. > >>> > : > >>> > : The difference shines when the beginning marker can look like the > end > >>> > : marker. > >>> > > >>> > The way I think of it is this: You come to the end of "ff" sooner, > so you > >>> > do the end test immediately after passing the start test. You come > to the > >>> > end of "fff" later, so the end test is delayed to the next iteration > from > >>> > the start test. (Same mnemonic for .. and ... in Perl, by the way, > since > >>> > ff and fff were modeled on .. and ... (in their scalar form), but we > stole > >>> > .. and ... in Raku for ranges and sequences so we needed something > else.) > >>> > > >>> > I suppose if you're musical you can come up with mnemonics based on > "fff" > >>> > being louder than "ff", so it echoes longer before it stops... :) > >>> > > >>> > Larry >