🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
[Coke] yay, fixed macport issue. apple.stackexchange.com/questions/...er-big-sur 00:10
I recall a bug reported with URI? 00:29
(seeing one on install, don't see it in the issue tracker for URI)
[Coke] github.com/jonathanstowe/URI-Template/issues/3 - trying with a released version of rakudo now 00:33
japhb [Coke]: github.com/raku-community-modules/URI/issues/48 02:01
[Coke] That module didn't show up when I searched for "URI" on the modules site. 02:01
(nor is it the one that zef found for me, I don't think)
japhb That's ... suboptimal. 02:02
[Coke] 'zef info URI' points at jonathanstowe/URI-Template; maybe it's a partial match?
closed mine 02:03
japhb [Coke]: Note this mismatch: 02:04
- Info for: URI
- Identity: URI::Template:ver<0.0.9>:auth<github:jonathanstowe>:api<1.0>
- Recommended By: Zef::Repository::Ecosystems<cpan>
- Installed: Yes, as URI:ver<0.3.3>
The versions don't line up.
I think `zef info` is confused. But at least when it's installed, it gets the 0.3.3 one. 02:05
ugexe i see whats causing that 02:09
looks like a regression from github.com/ugexe/zef/commit/a12d28...caae6268cf 02:12
should be fixed by github.com/ugexe/zef/pull/424 02:13
[Coke] ugexe++ # quick turnaround time 02:16
gfldex lolibloggedalittle: gfldex.wordpress.com/2021/11/05/timtowtditime/ 09:28
gfldex lolibloggedagain: gfldex.wordpress.com/2021/11/05/sh...r-not-yes/ 09:50
I am happy to report this to be post No. 150. Raku is BIG! 09:51
Nemokosch 😂 10:59
melezhik lizmat is it possible to keep logs for #raku-news channel? 14:41
lizmat they are already kept
melezhik cool
lizmat logs.liz.nl/raku-news/live.html
melezhik thanks! great 14:42
melezhik I've just added shortcuts support for raku.land and github http links to mybfio comments - mybf.io/project/mybfio/reviews#mel...1636123442 15:52
Od1n hello people 19:52
i need some help to transform this perl line in raku : map /type_(.*)/, qw< foo bar type_min type_max >
the best i have is gather for qw< foo bar type_min type_max > { take ~$0 if /type_(.*)/ } 19:58
Od1n better but not as simple as the perl version : map { ~$0 if /type_(.*)/ }, < foo bar type_min type_max > 20:01
lizmat is the match guaranteed ? 20:12
ah, I guess not
so you'd want the result to be <foo bar min max> ? 20:13
or just <min max> # my perl is a bit rusty
Od1n ^^
Od1n lizmat: hi! thanks for replying. there is no guaranty: those are filenames i parse and some data clearly are missing 20:17
lizmat so what is your expected result from your example? 20:18
Od1n it's so weird i can show you something in perl :)) actually: when you use captures in a list context, perl release the captured parts 20:20
so yes < min max > is expected
the real raku code here is : types => (map { ~$0 if /type_(.*)/ }, soft.dir)
(for the moment
lizmat m: <foo bar type_min type_max>.map: { . 20:21
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call (only basic method calls that exclusively use a dot can be detached)
at <tmp>:1
------> 3<foo bar type_min type_max>.map: { .7⏏5<EOL>
lizmat m: dd <foo bar type_min type_max>.map: { .Str with .match(/ type_ <( .* /) } 20:23
camelia ("min", "max").Seq
lizmat re <( see docs.raku.org/language/regexes#Cap..._%3C(_)%3E 20:24
Od1n arghhh ... i always forget them. my raku isn't fluent enough at all 20:30
thank you so much lizmat
lizmat m: dd <foo bar type_min type_max>.map: { ~$/ if / type_ <( .* / } 20:31
camelia ("min", "max").Seq
lizmat a bit shorter, but more linenoisy
I've grown to appreciate the less line-noisy variants 20:32
Od1n well ... the same to me when in comes to shell scripting (sed regexps are boring to maintain) but raku has a very acceptable way to be noisy 20:36
lizmat BTW, I was disappointed to see that / foo <( / would not simply fetch everything after the first "foo" 20:38
sadly the .* is needed
Od1n fair enough here. i'm more disappointed by the fact i need an entire block when just a regexp used to make the job done. trade offs ... but no doubt raku is the best deal 21:10
lizmat Od1n but you have a block in your perl code as well ? 21:14
Od1n nope, just the regexps: map /type_(.*)/ @foo returns all the captures that was matched in @foo 21:15
map /type_(.*)/, @foo , sorry 21:16
lizmat m: dd <a b c>.map: / b / # not sure why this couldn't work 21:17
camelia No such method '!cursor_start' for invocant of type 'Str'
in block <unit> at <tmp> line 1
Od1n /type_(.*)/ is simpler than { $~/ if / type_ <( .* / }
lizmat ~$/ actually, but yeah 21:18
Od1n ~$/ ... sorry
yes :)
lizmat hmmm.. that feels like something that could be pursued :-)
Od1n :) 21:19
"it would be great"
map / type_ <( /, @foo should be the ultimate goal
lizmat it would, wouldn't it :-) 21:20
Od1n indeed :)
ugexe >>.comb(/ ... /) ? 21:26
lizmat ugexe: indeed, I guess I was lead too much by the perl idiom 21:29
Od1n ^^
m: dd <foo bar type_min type_max>.comb: / type_ <( .* / 21:30
camelia ("min type_max",).Seq
lizmat m: dd <foo bar type_min type_max>.comb: /:g type_ <( .* /
camelia 5===SORRY!5=== Error while compiling <tmp>
Unrecognized regex modifier :g
at <tmp>:1
------> 3dd <foo bar type_min type_max>.comb: /:7⏏5g type_ <( .* /
expecting any of:
argument list
term
Od1n wow ... same problem as lizmat: i try too much translating my perl ideas in raku 21:31
thanks ugexe
Od1n ugexe: but not exactly: if there is no match, the entire string is returned so there are a lot of false positive 21:33
i'm checking for the parameters of .comb
lizmat m: dd <a foo_b foo_c>.comb: / foo_ <( .*? >> / # slight mod on the regex 21:34
camelia ("b", "c").Seq
lizmat m: dd <a foo_b foo_c>.comb: / foo_ <( \w+ / # alternate version 21:35
camelia ("b", "c").Seq
Od1n haha. this one works but i don't understand why
>> is unseen to me
docs.raku.org/language/regexes#ind...ex__%C2%BB 21:36
lizmat word boundary at right
Od1n yes. as i just read but why is this enough to remove the others
ugexe .comb on a list is stringifying the list, no? 21:37
lizmat ugexe: eh, yes of course
Od1n ahhhhh ... got it! thanks
lizmat m: dd <foo bar type_min type_max>>>.comb: / type_ <( .* /
camelia (().Seq, ().Seq, ("min",).Seq, ("max",).Seq)
lizmat m: say <foo bar type_min type_max>>>.comb: / type_ <( .* / 21:38
camelia (() () (min) (max))
Od1n wicked!
nope: soft.dir>>.comb( /type_<(.*/ ) gives me an error 21:40
'fluent/fluent150' is a directory, cannot do '.open' on a directory 21:41
but .comb: / foo_ <( .*? >> / made me happy :)
Tirifto Is there a way to somehow precompile code which is about to be EVALuated (multiple times) – that is, when it does not come from a module? 21:56
Od1n are raku.land and modules.raku.org different facets of the same ecosystem ? 22:05
lizmat yes 22:09
modules.raku.org is basically what modules.perl6.org used to be 22:10
raku.land is a new thing, based on Cro
Od1n ok. so there is no implementation of Template::Toolkit in raku.
ahh cool! cro in production !
lizmat also: logs.liz.nl # also cro, and also production :-) 22:11
if you're thinking about templating in Raku, I've become pretty enamoured by Cro::WebApp
Od1n your irc logs are gorgeous! i like it 22:12
lizmat thank you :-) 22:13
Od1n actually i need static pages
lizmat logs.liz.nl/raku/2021-11-04.html is actually a static page 22:14
Od1n build with cro ? 22:15
lizmat yup
and Cro::WebApp 22:16
Od1n is there a chance to pull the code of logs.liz.nl ?
lizmat github.com/lizmat/App-Raku-Log/issues
and all the modules that it uses :-)
github.com/lizmat/App-Raku-Log
actually :-)
Od1n thank you so much! i'll study this 22:17
lizmat not a lot of docu yet, as a lot is still in flux
but the modules that are used, are better documented
github.com/lizmat/App-IRC-Log for erxample
Od1n reading raku code is something i have to exercize on so it's ok :) 22:18
but for now got to sleep. thank you again
lizmat sleep well!
and you're welcome :)
Od1n have a nice week-end rakoons
lizmat thanks, we will :-) 22:19