🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
01:23 chmod222 left 02:43 hulk joined 02:44 kylese left 03:15 hulk left, kylese joined 03:37 edr left 06:17 jpn joined 06:23 jpn left 06:29 abraxxa joined
librasteve m: sub foo(--> Array(Int())) { return [1,2,3] }; say foo 07:08
evalable6 [1 2 3]
Raku eval [1 2 3]
librasteve the extra () does a coercion on the return type (timtowdi) 07:09
07:42 jpn joined 08:11 jpn left 09:11 dakkar joined, sena_kun joined
Geth advent/main: 149c435240 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | raku-advent-2023/authors.md
Add japhb's blog posts
 09:57
10:24 MoC joined 10:25 jpn joined
SmokeMachine lizmat: hi! I was reading your post today and I have a question… for your REPL example, don’t we already have something like that with something like this? glot.io/snippets/graene67b2 10:28
lizmat You mean the post by Kay Rhodes ?
SmokeMachine (I mean the future of pod6 post) 10:29
lizmat right
that's not my post
SmokeMachine Oh! Sorry…
lizmat www.reddit.com/r/rakulang/comments...ay_rhodes/
Ralph Mellor has extensive replies there
SmokeMachine Thanks
lizmat which I think also address the point your making :-) 10:30
*you're 10:31
10:39 jpn left 10:41 jpn joined 10:57 andinus left 10:58 andinus joined 11:04 constxqt_ left
nemokosch hobbs: I just found something raku.land/zef:Scimon/Range::SetOps 11:04
tellable6 nemokosch, I'll pass your message to hobbs
nemokosch but this also doesn't seem to be precise about endpoints at first sight 11:06
which it actually states as well github.com/Scimon/p6-Range-SetOps/issues/1
ab5tract I think the broader point was that we don't necessarily have cultural norm around documentation. some people might use the approach SmokeMachine shared but others might use a more elaborate Raku doc block or maybe they will document everything at the end so that they have control over the ordering of the information displayed 11:19
Also, a lot of us probably consider Raku code relatively self-documenting and skip the documentation stage altogether 11:20
11:21 Sgeo left
ab5tract This would work better if you could arbitrarily summon the implementation code of any given method. "Get me docs and/or code" 11:22
lizmat I wonder whether we should have a pragma like "use keepast" that would introduce a meta-method on each object that could be used to obtain the original RakuAST of that object 11:24
so you could do: use keepast; class A { method frobnicate { } }; say A.^AST 11:25
SmokeMachine ab5tract: I'm in the group that thinks raku code usually is self-documenting, but thinking that my documentation chould help users of my modules as hints while they are writing code would make me want to write docs...
ab5tract SmokeMachine: agreed! 11:26
lizmat: I think that's an interesting idea!
but I would recommend `keep-ast` 11:27
SmokeMachine lizmat: how would that work on modules? would my custom `map` method inside Red::ResultSeq be able to get the block's ast?
lizmat yes, $block.^AST should then work
SmokeMachine where do I sign?
11:28 donaldh left
lizmat well, it would have to be opt-in, so the user of your module would have to have done the "use keep-ast" 11:28
ab5tract It should be a core pragma instead of something that has to be installed
lizmat pragmas only work lexically, not dyamically
ab5tract: agree, would be *very* hard to do otherwise 11:29
ab5tract but that's kind of way better in a way
then you can enable for just the scope you are concerned about, and the rest of the program doesn't have to keep that state
lizmat I mean, whenever we attempt to get the meta-object in RakuAST, it should check the pragma and set the right attribute in the meta-object
I guess all meta-objects would get an .AST attribute then 11:30
SmokeMachine if it were dynamic, I think it would be better to Red... maybe not... but it would be cool if when someone adds `use Red` it would also adds the pragma...
11:30 constxqt_ joined
lizmat yeah, that's another one on my wish list :-) 11:30
ab5tract dynamic pragmas? 11:31
lizmat no, being able to set pragmas in the scope where a "use" is done, from the module's EXPORT logic
so that a "use Red" in a scope would automatically also mean "use keep-ast" 11:32
ab5tract SmokeMachine: Depending on the performance/memory impact of the feature, I would think that might be a rude surprise for the application importing your library
lizmat ab5tract: ORMs are generally about convenience, not necessarily about performance 11:33
SmokeMachine ab5tract: even if explained on docs?
ab5tract ahh, I see what you mean. Once we have macros, that should be straightforward I believe
lizmat also: a "no keep-ast" after the "use Red" would also be an option
ab5tract lizmat: could you not already right now inject a use statement via AST at begin time? or maybe that would only work from the importing code, not from the module's export 11:34
11:35 constxqt_ left
lizmat if you have the AST before it is EVALled, you could 11:35
hmmmm
SmokeMachine talking about macros... why "method-like" macros couldn't be a thing? I mean, my problem on Red (I think), would be easily fixed if I could write a `$obj.map` macro... it wouldn't need to be "coupled" to a class... $obj could just be another parameter... as if I called like `$obj.&map` if it was a sub... 11:36
ab5tract SmokeMachine: I would always
lizmat I guess, if you put a "use Foo" at the end of your code, it could technically access the whole AST of the program, and do things to it 11:37
ab5tract * do something like that as opt - in, for my own libraries
lizmat SmokeMachine: have you looked at the way .race and .hyper are implemented ?
ab5tract lizmat: intriguing!
lizmat another idea I had, would be a Linter::Decking module 11:38
ab5tract I grok the linter part but I need help with "decking"
lizmat that would produce a report of a source-file on which parts of the code *could* have a Declarater::Doc, but didn't
SmokeMachine lizmat: not after I have a minimal condition to possibly understand them... I'll take another look (today if there are wifi on my plane...)
ab5tract ah, interesting! that's something that would go very well into an LSP 11:39
SmokeMachine #| decking?
lizmat aah... I remember the days of Airplane Mode :-)
yes, the term Ralph Mellor introduced in www.reddit.com/r/rakulang/comments...ay_rhodes/
SmokeMachine talking about RakuAST, have anyone thought on a easy way to match RakuAST on code and/or on search tools? 11:44
I had given it a try some time ago... but I'm not sure if I'm happy on where that was going... (github.com/FCO/RakuAST-Matcher) 11:45
nemokosch the Ralph Mellor phenomenon, how to put it... 11:47
I don't think there is a way to say it without somebody interjecting that this is a personal attack
11:49 constxqt_ joined
It's not really healthy when one individual - whoever that might be - dominates all Raku-related discourse and gets to represent very personal user takes as the ultimate truth all the time 11:51
what is even less healthy if these personal takes include a lot of sending users back to learn more whenever something is genuinely odd 11:52
11:52 grondilu joined
grondilu Hi. Partial permutations are not implemented in core, right? en.wikipedia.org/wiki/Partial_permutation 11:54
lizmat grondilu: couldn't you do something with Z ? 11:55
grondilu: looking deeper at the WP article, I don't think Raku has that 11:57
grondilu oh wait I'm not sure this article is what I had in mind. 11:58
what I had in mind is all the ways to pick n elements from a set, with the order being significant. 11:59
basically all possible outputs of *.pick($n)
nemokosch so pick and permutate? lol 12:00
lizmat wouldn't that just be Set.combinations? 12:01
nemokosch although that might mess with the distribution, I wouldn't know offhand
grondilu no becauase with combinations the order does not matter.
lizmat wouldn't that just be Set.pick($n).combinations?
ah...
wouldn't that just be Set.pick($n).permutations I meant :-)
grondilu lizmat: ah you may be right 12:02
hang on
no
maybe *.combinations($n)>>.permutations 12:03
lizmat that sounds like a lot of permutations, and heat death of the universe code :-) 12:04
grondilu it's lazy so it's ok
m: say (^4).combinations(2)>>.permutations 12:05
camelia (((0 1) (1 0)) ((0 2) (2 0)) ((0 3) (3 0)) ((1 2) (2 1)) ((1 3) (3 1)) ((2 3) (3 2)))
grondilu that seems fine but how do I flatten this to the correct level?
m: say (^4).combinations(2)>>.permutations.flat
camelia (0 1 1 0 0 2 2 0 0 3 3 0 1 2 2 1 1 3 3 1 2 3 3 2)
grondilu ^that's too flat
m: say (^4).combinations(2)>>.permutations.rotor(2) 12:06
camelia ((((0 1) (1 0)) ((0 2) (2 0))) (((0 3) (3 0)) ((1 2) (2 1))) (((1 3) (3 1)) ((2 3) (3 2))))
grondilu m: say (^4).combinations(2)>>.permutations.flat.rotor(2)
camelia ((0 1) (1 0) (0 2) (2 0) (0 3) (3 0) (1 2) (2 1) (1 3) (3 1) (2 3) (3 2))
lizmat if you use .map instead of >> you have more control
grondilu m: say (^4).combinations(2).map(*.permutations.Slip)
camelia ((0 1) (1 0) (0 2) (2 0) (0 3) (3 0) (1 2) (2 1) (1 3) (3 1) (2 3) (3 2))
grondilu that works
nemokosch what is correct level btw 12:07
grondilu a list of lists 12:08
not any deeper
nemokosch gotcha 12:10
tbrowder__ ugexe: what will happen if one changes source code in his ~/.raku/sources/* file? 12:11
grondilu if you're curious I thought I needed this to generate all possible knight moves on a chess board. I've just realized there is a simpler method lol 12:12
(and actually correct, as what I was planning was wrong) 12:13
I ended up doing something like (<up down> X, <left right>).map(*.permutations.Slip).map({ flat .head xx 2, .tail }) 12:15
m: say (<up down> X, <left right>).map(*.permutations.Slip).map({ flat .head xx 2, .tail }) 12:16
camelia ((up up left) (left left up) (up up right) (right right up) (down down left) (left left down) (down down right) (right right down))
nemokosch did you see my issue on GH 🥺
grondilu well I see it now 12:17
what does 'the commits alter the p6c instance' mean? 12:18
lizmat on use v6.*; use nqp; say nqp::istrue(1..0) 12:19
it looks like nqp::istrue is calling the 6.d Mu.Bool instead of the 6.e Range.Bool 12:20
so it looks like nqp::istrue is unaware of the language change
nemokosch interesting 12:25
how does it call that? I tried to trace the behavior but failed miserably
grondilu: p6c has no versioning, it's basically just the HEAD of your base branch 12:26
12:32 jpn left
ab5tract I'm also curious about how lizmat++ got that figured out 12:39
lizmat adding an nqp::say to Mu.Bool :-) 12:43
hmmm I might actually be wrong about that on further investigation... 12:48
but first afk for a few hours&
13:06 jpn joined 13:23 sdfgsdfg left 13:49 MoC left 13:52 derpydoo joined 14:02 sdfgsdfg joined 14:34 mscha joined 14:36 mscha left 14:39 edr joined 15:19 vrurg left 15:20 vrurg joined 15:28 vrurg left, vrurg joined 15:48 jpn left 15:57 jpn joined 16:54 sdfgsdfg left 16:58 jpn left 17:22 F3nd0 joined
F3nd0 Hello! Is Pod::To::HTML still the module to have when trying to export POD6 to HTML? 17:25
17:31 dakkar left 17:32 sdfgsdfg joined
nemokosch I have the feeling that there is a hidden question here. Why do you ask? 17:47
F3nd0 Well, trying to install it with zef reports that Raku::Pod::Render could not find ‘npm’, which seems like a very bizzare external dependency for such a module to have. So I thought maybe this wasn’t the module I should be trying to install. 17:54
ab5tract 0_0 17:57
F3nd0 (Apparently Raku::Pod::Render uses ‘npm’ for some highlighting functionality, which is disabled by default when building newer versions, but that does not appear to be the case for the version which Pod::To::HTML explicitly makes zef build.) 17:59
ab5tract oh, nice.. 18:00
nemokosch Right in the middle of it, as I thought 😄
there are modules and there are distributions 18:01
ab5tract .seen finanalyst 18:02
tellable6 ab5tract, I saw finanalyst 2023-10-31T16:14:01Z in #raku-dev: <finanalyst> [Coke] thanks. Let me know if there's something urgent to do on doc-website
nemokosch Now, Pod::To::HTML used to resolve to a certain older distribution
raku.land/github:Raku/Pod::To::HTML
Then raku-pod-render came and it had a module that was also called Pod::To::HTML and basically hijacked the resolution 18:03
then the author wanted to avoid this hijacking and renamed the module in raku-pod-render to Pod::To::HTML2 18:04
F3nd0 Oh dear.
nemokosch so you either should retrieve Pod::To::HTML with the appropriate metadata
or Pod::To::HTML2 18:05
perhaps the latter is more maintained
F3nd0 Ohhh. I see now that ‘zef info Pod::To::HTML’ does report on ‘Raku::Pod::Render:ver<3.5.2>:auth<github:finanalyst>’. 18:07
While ‘zef info 'Pod::To::HTML:auth<github:Raku>'’ reports on the actual module called Pod::To::HTML. 18:09
nemokosch unfortunately, the distinction between "module" and "distribution" is important to get right 18:10
Raku::Pod::Render:ver<3.5.2> has a very actual module called Pod::To::HTML - that's why it got installed for you in the first place
F3nd0 Is there somewhere I can read up on the distinction? 18:11
nemokosch frankly, I have never seen a convincing argument for this system
I just hope that the chaos reaches a level where it simply must be addressed
F3nd0 Are ‘distributions’ what is being listed on raku.land? 18:13
> Raku Land is a directory of Raku
distributions.
Oh.
nemokosch perl6advent.wordpress.com/2016/12/...ained-ish/ 18:14
long story short:
most of the time, you give the name of a module (which is sort of a blessed namespace with some metadata) and this module is resolved to a distribution that can provide it 18:16
then this distribution can be installed with all the code, tests, resources, building etc. 18:17
and then suddenly you have a bunch of modules you can use in your code: the ones that the META6 file of the distribution provided (literally - the "provides" section defines how they have to be mapped to code) 18:18
the way I understand it, the usual thing is that modules are installed to a global place and resolved from there; this is another reason why the metadata specification is important 18:21
F3nd0 Oh, I see. So a distribution is an installable unit providing some modules and extras. So when I install a module with zef, it finds a distribution that provides it, which might be a simple distribution made specifically to provide that one module, or it might contain a bunch of modules, one of which might be the one I want. Did I get that right?
nemokosch yes 18:25
there are also distributions that have no modules whatsoever, just some executables, or technically it could be that they have nothing at all (although that's probably a weird use case lol) 18:26
therefore sometimes the dist name is still needed to install something - but other than that, the module name just trumps it 18:27
F3nd0 Okay… I’ll have to let that sink in… but for now I’m glad to understand what went wrong. xP 18:28
nemokosch I'm still (not-so-secretly) hoping that there is a way to break away from this completely. It's too apparent that the dependencies are really the distributions, and hence they should serve as the basis for any sort of installation 18:29
like they do in Pakku, from what I know
F3nd0 Since the build of the most recent version of Raku::Pod::Render fails, I’ll try the actual Pod::To::HTML this time. x) 18:30
Is Pakku an alternative to Zef, or do they have different use cases? 18:32
nemokosch I don't really know, honestly. I think in theory Pakku aims to do whatever zef can do, without depending on it. 18:36
what system is it failing on?
F3nd0 openSUSE LEAP 15.5, at the moment. Yesterday it has also failed on Debian 12, though. (Although I think I didn’t get as detailed of an output there.) 18:38
nemokosch which version of Rakudo?
F3nd0 Ah, somewhat outdated, without a doubt. 18:39
2023.04 over here.
nemokosch it just installed for me Ubuntu 22.04 in WSL2, Rakudo 2023.06
that should be good enough I think
F3nd0 Should work for v6.d, unless it’s bugged. 18:40
nemokosch doing a full installation now with Rakudo 2023.04 18:41
oh right... I wouldn't think too much of language versions at this point 🥲
in any case, it does fail with Rakudo 2023.04... that was easy 18:43
bisectable: say Pod::Block::Input 18:44
bisectable6 nemokosch, Will bisect the whole range automagically because no endpoints were provided, hang tight
nemokosch, Output on all releases: gist.github.com/7f08befc67a30cbcb3...40b04caa7c
nemokosch, Bisecting by exit code (old=2023.04 new=2023.05). Old exit code: 1
nemokosch so it was right on the turn xD 18:45
should have bisected it tho 18:47
github.com/rakudo/rakudo/commit/6f...94ec7bb6c4 18:48
bisectable6 nemokosch, bisect log: gist.github.com/9736ee2adc8e0cc9a6...71b94e9e24 18:57
nemokosch, Bisecting by output (old=2020.01 new=2020.02.1) because on both starting points the exit code is 1
nemokosch lol, that took a while
bisectable6 nemokosch, bisect log: gist.github.com/b921566c46931404e5...c1311e434d
nemokosch, (2020-02-08) github.com/rakudo/rakudo/commit/ca...cf73e3fda7
nemokosch, Bisecting by output (old=2017.05 new=2017.06) because on both starting points the exit code is 1
nemokosch AlexDaniel: what happened here?
bisectable6 nemokosch, bisect log: gist.github.com/66ffd5c4afac2e0163...ab9c93b154
nemokosch, (2017-06-07) github.com/rakudo/rakudo/commit/e5...30bd74d765
tellable6 nemokosch, I'll pass your message to AlexDaniel
bisectable6 nemokosch, Output on all releases and bisected commits: gist.github.com/c0d2afb48dae850850...9f2f3f17aa 18:58
19:10 chmod222 joined
chmod222 I'm currently doing advent of code and I have noticed a peculiar (to me) behaviour with regex code interpolation: On an input of 1000 short lines, the regex "/<{BEGIN { Card.keys.join: '|' }}>/" runs in about 100ms, whereas "/<{ Card.keys.join: '|' }>/" requires 50 seconds 19:12
I wonder, what could cause this explosion in runtime if not forcing it to run at parse time?
Even recompiling the regex for every iteration should not yield that kind of increase at only 1000 iterations I'd think 19:13
Obviously it's not a huge issue since it's easily workaroundable, but it piqued my interest 19:14
(On Raku 2023.11 by the way, or a few commits on master behind that tag) 19:15
Oh yeah, and "Card" is an enum so this results in a regex that matches all enum names 19:18
[Coke] m: my @a= [1,2,[3,4]]; dd @a.fmt("%5s") 19:20
camelia " 1 2 3 4"
[Coke] huh.
nemokosch chmod222 - it runs on each parsing attempt i think 19:31
chmod222 Even if it's stored in a $var that's only initialized once? 19:33
Good to know if I ever want to interpolate with side effects
Not sure why I'd want that but more tools are always fun 19:34
librasteve fwiw@i would vote for a better way to write “<{Card.keys.join: ‘|’}> to match an enum in a regex ( i guess Card.keys also works btw) 20:00
chmod222 In this case it was pure laziness because I didn't feel like repeating myself with manually|spelling|out|all|the|names but ye 20:01
Actually, "<{Card.keys}>" does work but only without the BEGIN {} workaround 20:02
20:04 andinus left 20:06 andinus joined
chmod222 Funnily enough, that is even slower, it's been running for over 2 minutesn ow 20:07
If I store "Card.keys" in a new @variable and interpolate that one, we're back down to 350 - 400ms 20:08
So it seems to be a case of Enum.keys being not that fast and then being called entirely too often 20:10
20:12 Sgeo joined
tonyo .seen rf 20:13
tellable6 tonyo, I saw rf 2023-08-07T20:59:12Z in #raku: <rf> Where does this person get gremlins from? Besides that I think they liked Raku?
20:39 abraxxa left 21:36 codesections1 joined 22:08 jpn joined 22:23 jpn left 22:28 chmod222 left 22:41 codesections1 left 23:26 derpydoo left 23:56 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!