| 18 Apr 2024 | |||
| greenfork | lizmat: Oh wow! I didn't know it exists, it is a perfect debugging tool too! | 17:33 | |
| lizmat | yeah, it was intended as such :-) | 17:34 | |
| docs.raku.org/type/independent-rou...s#sub_repl | |||
| greenfork | @antononcube ^^^ this is awesome | 17:40 | |
| antononcube | @greenfork Well, I cannot make that advice by ugexe work for me. How did you apply it? | 20:53 | |
| .ohnowendigo | m: say (/[\w\d]+/, /[\w\d]*/).map: {"xa5".match($_)} | 21:41 | |
| Raku eval | (｢a5｣ ｢｣) | ||
| .ohnowendigo | Why is the + able to match the a5 while * cannot? Aren't both supposed to be greedy? | 21:42 | |
| antononcube | Because matching nothing with * is a match. | 21:45 | |
| @.ohnowendigo Try it with the adverb :ex . | 21:46 | ||
| say (/[\w\d]+/, /[\w\d]*/).map: {"xa5".match($_):ex} # ((｢a5｣) (｢｣ ｢a5｣ ｢｣ ｢｣ ｢｣)) | 21:47 | ||
| 19 Apr 2024 | |||
| greenfork | @antononcube I was actually referring to the repl command, since it effectively solves the problem of inspecting file contents after the file was run | 04:44 | |
| But since you asked, here is an example that works for me: paste.sr.ht/~greenfork/4cecd40746d...ae6b07664e | |||
| You will need to change the path to the file, and after running the imported.raku, you will see two messages printed, first from exported and second on use | 04:45 | ||
| s/imported/importing/ | 04:46 | ||
| antononcube | @greenfork Great! It is how ugexe adviced. What if the file name has white spaces? | 10:47 | |
| greenfork | @antononcube I have just put a space there, it worked: require WHATEVER:file</home/grfork/for export.raku> | 12:10 | |
| antononcube | I find that surprizing! 🙂 | 12:52 | |
| greenfork | Well I guess it's good as long as it works :^) | 16:17 | |
| 22 Apr 2024 | |||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/04/22/2024-...dcabaacab/ | 17:19 | |
| dr.shuppet | Luckily that abaacab issue turned out to be an ordinary kind of bug, nothing scary 🙂 | 17:20 | |
| lizmat | indeed, although any sufficiently advanced bug can appear to be magic! :-) | 17:21 | |
| dr.shuppet | Well, the strange symptoms that I observed turned out to have been caused by a clever implementation of strings | 17:29 | |
| Clever enough to make the cause of the bug not easily visible 😄 | 17:30 | ||
| 24 Apr 2024 | |||
| .admeliora | I'm not much involved with Rakudo/NQP development, hell i don't write even that much of raku in the first place, but still interesting read and the bug was definitely amusing | 11:09 | |
| 25 Apr 2024 | |||
| ab5tract | glad my pain could bring some smiles into the world ;) | 16:44 | |
| timemelon | I'm getting some behaviour from regexes that I don't understand | 22:30 | |
| I'm used to * and + from PCREs | |||
| echo 'words: 12345' | grep -oP '\d+' and echo 'words: 12345' | grep -oP '\d*' both return 12345 | 22:31 | ||
| when I try echo 'words: 12345' | raku -e 'slurp.match(/\d+/).Str.say' I get 12345 just the same | 22:32 | ||
| but echo 'words: 12345' | raku -e 'slurp.match(/\d*/).Str.say' gives me an empty match | |||
| how come \d* doesn't match 12345? | 22:33 | ||
| (also: is this the most idiomatic way to use raku as a drop in grep/sed/etc) | 22:36 | ||
| ab5tract | it matches '0 or more', so when it hits that first 'w' from words, it has successfully matched 0 times | 22:47 | |
| definitely a bit of a gotcha, though, I agree | 22:48 | ||
| m: "words: 12345" ~~ /\D+(\d*)/ ==> say() | 22:50 | ||
| camelia | ｢words: 12345｣ 0 => ｢12345｣ |
||
| ab5tract | or to drive the '0 or more' rule home: | 22:51 | |
| m: "words: 12345" ~~ /\D*(\d*)/ ==> say() | |||
| camelia | ｢words: 12345｣ 0 => ｢12345｣ |
||
| timemelon | ahh that makes sense thank you | 22:53 | |
| I guess the difference between the grep example and that is that grep is finding the longest match while raku is finding the first match | |||
| ab5tract | yeah, we tend to refer to it as the "greediness" of the regex expression | 22:54 | |
| * is very gregarious, not greedy at all :) | 22:55 | ||
| As to the idiom, I might me more likely to use `$*IN.slurp ~~ /regex/` but it's really a matter of taste | 22:58 | ||
| There's also `-n` which allows: `echo "words: 12345" | raku -ne '$_ ~~ /\D*(\d*)/ ==> say()'`\ | 23:01 | ||
| timemelon | oh I didn't know about -n, that's nice ty | 23:25 | |
| is there a reason you prefer the explicit $*IN over a bare slurp? | 23:27 | ||
| 26 Apr 2024 | |||
| ab5tract | Nothing technical, no | 07:35 | |
| nahita3882 | there is also -p to print $_ at the end of processing each line but well it requires what you want printed stored in $_, so might be less readable in this case | 08:09 | |
| :/tmp$ <<< $'hi 445\nhere 78' raku -pe'$_ = m/\D* (\d*)/' ｢hi 445｣ 0 => ｢445｣ ｢here 78｣ 0 => ｢78｣ | 08:10 | ||
| timemelon | thanks for the tip! I had a play around with that and found .=match(...).=Str which is kinda neat too | 11:02 | |
| ab5tract | ah yeah, implicit method dispatch on the topic is great | 11:52 | |