This channel is intended for users of App::Rak
Set by lizmat on 27 September 2022.
lizmat just realized I could do: 10:19
% ps ax | rak §vi
to find all of my vi processes :-)
just looking for "vi" including all of the "Service" lines as well 10:20
Geth App-Rak/main: 2927a3b4a1 | (Elizabeth Mattijsen)++ | 2 files
Allow postcircumfix[] on strings to index into the .words

This looks like it is the most useful functionality within the context of Raku code patterns
App-Rak/main: 4f1e0526ce | (Elizabeth Mattijsen)++ | 2 files
Default to *not* showing line numbers when reading from STDIN.

Feels to me that is the most sane thing to do
SmokeMachine §vi? I don't get it... 15:46
lizmat: I've been wondering about a simpler version of `rak`... that would be able to receive between 1 and 3 code blocks. one that would run for each file (defaults to: `{ .relative => .lines }`) it would receive a IO::Path and return a list of items to be matched by the 2nd block. The 2nd block would receive one of those items returned by the first one (if the first block is not changed, that would be a line) and it would use 16:14
the object on `$*PARENT-ITEM` to `.add-item` the matched item (defaults to: `{ $*PARENT-ITEM.add: $/ if /pattern/ }`). And the last block would receive a list of Item objects and each obj would have a list of children objects, to print it out (the default would be: `{ gather { for .<> { take "{ .name }:"; take "{ .item-index }: { .highlighted-match }".indent: 4 } } }`).
lizmat: I'm not sure I'm mentioning this here... I do not intent on implementing it... but I can't stop thinking on it... 16:15
lizmat §vi is short for vi --type=words
--per-line takes a code block that's given an IO::Path and is supposed to create items to search in
so that part is there already 16:16
rak --per-line='*.lines.head(5)'
would only look in the first 5 lines of each file
internally, there is a mapper functionality that sorta is what you describe 16:17
but I'm still unsure how to externalize it
SmokeMachine: please distill what you would like to achieve in an example in an issue, so that I can also ruminate about it :-) 16:18
SmokeMachine lizmat: I'm not sure if I'd like to achieve anything... :( 16:19
using that, something to, for example, find the name of every module where you are the author (assuming a list of modules) would be something like: `not-rak '{ .slurp.from-json if .basename eq "META6.json" }' '{ $*PARENT-ITEM.add: $_ if .<author> eq "lizmat" }' '{ .content<name>.say for .<> }'` 16:26
lizmat: does that make any sense? 16:27
lizmat rak --json-per-file {,<name> if .<auth> eq "zef:lizmat"} 16:28
rak --json-per-file {.<name> if .<auth> eq "zef:lizmat"}
SmokeMachine yes, that makes sense and is much smaller... 16:29
lizmat in the REA dir: 16:30
rak --json-per-file '{.<name> if .<auth> eq "zef:lizmat"}' meta --quietly --unique
SmokeMachine yes... I don't know... I think I was just finding a way to not need all those parameters... but that doesn't make much sense... 16:33
lizmat if you do this often, you can do:
rak --json-per-file --pattern='{.<name> if .<auth> eq "zef:lizmat"}' --quietly --unique --save=module-names 16:34
and then go:
rak --module-names meta
SmokeMachine no, I don't do that often... but something I do often is reading all the options... I think that's what I was trying to avoid... but that doesn't make sense... 16:37
lizmat well, you could also create your own set of shortcuts
SmokeMachine yes
lizmat rak --json-per-file --save=j
rak --quietly --save=q 16:38
rak --unique --save=u
and you could do:
rak -jqu '{.<name> if .<auth> eq "zef:lizmat"}' meta
afk& 16:51