🦋 Welcome to the former MAIN() IRC channel of the Raku Programming Language (raku.org). This channel has moved to Libera (irc.libera.chat #raku)
Set by lizmat on 23 May 2021.
moon-child is there an 'apply' function? 02:01
elcaro what specifically do you want to do that isn't covered by .map or .reduce? 02:07
The only lisp I've used is Racket. Racket's `(apply + '(1 2 3))` can be expressed in Raku as `[+] (1, 2, 3)` or `(1, 2, 3).reduce(* + *)` 02:10
... among other ways 02:11
moon-child I think the more natural dual is |. E.G. infix:<+>(|<1 2 3>) 02:13
in this case I have a sequence of functions that I want to apply to a single object. Not hard to express, but it would be nice to be able to say [&f, &g, &h...].map(&apply.assuming: *, $object) 02:14
elcaro are you opposed to: (&f, &g, &g).map(-> &func { func($object) }) 02:16
moon-child not opposed, certainly. I just think the first version is a bit prettier 02:17
dac Sometimes when I start raku for the first time in a while it can take upward of 20 seconds to become interactive, is there anything that might be causing that? 02:18
moon-child probably precompiling the standard library. That only happens for when I upgrade 02:20
dcx Ah makes sense
It would be neat if there was just a small message saying that was happening, it's a little confusing 02:41
raydiak moon-child: if I understand correctly, you could also write (&f, &g, &h)».($object) 03:36
moon-child ooh, cool 03:43
thanks!
raydiak yw!
guifa Is there any way to inspect a package's outer symbol table? 04:18
e.g.
guifa class A { constant foo = 0; class B { constant bar = 1 } }; my \C := A::B; say B::.keys; 04:19
m: class A { constant foo = 0; class B { constant bar = 1 } }; my \C := A::B; say B::.keys; 04:20
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared name:
B used at line 1
guifa m: class A { constant foo = 0; class B { constant bar = 1 } }; my \C := A::B; say C::.keys;
camelia (bar)
guifa so that gets me the keys inside of class B
how could I get the keys inside of A (that is, <foo B>), by using C? I figured C::OUTER::.keys would work but it doesn't 04:21
lizmat: clickbaits rakudoweekly.blog/2021/05/24/2021-...hattering/ 08:28
Altreus has there always been a hero image at the top? 08:30
lizmat hero image ?
Altreus like when you have one big image for its own merit 08:31
lizmat yes, every issue of the Rakudo Weekly News had one
Altreus literally only just realised :D
although that's probably exactly how it should be
lizmat ah, I guess then I failed this week ? :-) 08:32
Altreus Well I thought of that too
Maybe I'm just more on the ball today :D
lizmat all but 2 of them, come from my personal picture collection 08:33
Altreus ones you've taken, or ones you've collected?
lizmat ones Wendy or I have taken 08:34
Altreus nice :) 08:35
raydiak thank you for another weekly lizmat++ 08:42
holyghost fucking netsplits 09:00
tyil just like in the old days
El_Che weekly: new rakudo-pkg 2021.05 09:08
notable6 El_Che, Noted! (weekly)
raydiak lizmat: I've been looking at your irc log. thank you again for working on it. do you want issues filed wrt the front end, or should it be regarded as a placeholder until the back end is more settled? 09:21
Altreus Has anyone else tried Joplin? I happen to be looking for a shared todo/notes app for the business 09:26
Small projects like the one on this weekly are good for word-of-mouth learning about other projects
dakkar for my notes & todo I use NextCloud, but that's a big PHP application suite (it replaced most of Google services for me, and it runs on my own server) 09:28
may not be appropriate for your use case
Altreus I think Opus uses NextCloud 09:37
I think there's also another thing with a similar name
That's gonna be useful in future when we don't want to rely on Google Drive for all our shared docs
dakkar OwnCloud, of which NextCloud is a fork?
Altreus ah that might be it 09:38
Didn't realise they were related!
one of them is good and works well - probably NextCloud
tyil nextcloud works great for me and the missus
dakkar it's free software with commercial backing, so it will probably not die soon ☺ 09:40
(AGPL-3)
El_Che Altreus: I use markdown and git 09:42
holyghost I started a NES Solstice game on github.com/theholyghost2/Solstice 09:43
just a side game project
Altreus El_Che: yeah, works for me but not for a business with other people in 09:44
holyghost still needs lots of work but there's some kind of a codebase
Altreus Especially ones who use email, and apps, and what have you
El_Che Altreus: ahm you're the social type :P
Altreus no I'm the CTO type, not the CEO type
Xliff_ m: multi sub infix:<*> (Int() $a, Int() $b) is equiv(&infix:<+>) is assoc<left> is default { say "A: $a / B: $b"; nqp::mul_I($a, $b, Int); }; say 1 + 2 * 3 + 4 * 5 + 6; 09:49
camelia ===SORRY!=== Error while compiling <tmp>
Could not find nqp::mul_I, did you forget 'use nqp;' ?
at <tmp>:1
------> A: $a / B: $b"; nqp::mul_I($a, $b, Int)⏏; }; say 1 + 2 * 3 + 4 * 5 + 6;
Xliff_ m: use nqp; multi sub infix:<*> (Int() $a, Int() $b) is equiv(&infix:<+>) is assoc<left> is default { say "A: $a / B: $b"; nqp::mul_I($a, $b, Int); }; say 1 + 2 * 3 + 4 * 5 + 6;
camelia A: 2 / B: 3
A: 4 / B: 5
33
Xliff_ I am trying to get * to act like + in terms of operator precedence. What am I doing wrong?
dakkar m: 4.^name 09:51
camelia ( no output )
dakkar m: say 4.^name
camelia Int
dakkar oh, it's not a type problem then
raydiak I'm not sure that adding another multi will work, there is already a candidate with Int args. you might have to change the precedence of the existing one 09:53
Xliff_ radiak: It's getting selected. See the output. 09:54
raydiak that's true...
Geth problem-solving: a830d70241 | (Elizabeth Mattijsen)++ | solutions/meta/move-repo-to-raku.md
Suggest moving to "raku" organisation

Note, this is only part of solving issue #280.		 09:55
problem-solving: 72008265ff | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | solutions/meta/move-repo-to-raku.md
Merge pull request #281 from Raku/move-repo-to-raku

Suggest moving IRC logs to "raku" organisation
raydiak I suspect it has something to do with how the core ops are written explicitly into the grammar... 10:02
github.com/rakudo/rakudo/issues/1237 10:04
dakkar also, having one candidate have a different *parsing* than others, is not exactly a sensible thing to do 10:08
because the parsing has to happen before all type information is available
Xliff_ radiak: OK. So how would I change the rule on the existing operator? 10:10
dakkar (maybe in 6.zz we should require precedence/associativity/&c to be declared on the `proto`, and not on the candidates?)
raydiak Xliff: it wouldn't work if I'm reading the code related to that bug correctly. the precedence of core ops is basically hard-coded into the grammar. best I can think to suggest off the top of my head is to just name your operator something else 10:14
Xliff radiak: Unfortunately, that's not a part of the problem space. 10:14
Xliff I will have to figure out another method. Thanks! 10:15
raydiak wouldn't hurt to add a comment to that bug along the lines of "this is a blocking issue for my current project" to get it a little more attention, but no guarantees. you're welcome, sorry I couldn't be more helpful 10:16
Xliff raydiak: You were helpful enough. Thanks! 10:17
raydiak wonder what the concequences would be if we just outright removed github.com/rakudo/rakudo/blob/mast...4547-L4549 10:19
Xliff We'd have to start a proto and create a candiate list for the dispatch as replacement behavior. 10:22
MasterDuke Stage start : 0.000
Error while compiling, type X::Comp::AdHoc
payload: don't change grammar in the setting, please!
Xliff I agree with you: straight up removal would cause problems.
MasterDuke at line 2239, near "(Mu, Mu, *"
at gen/moar/stage2/NQPHLL.nqp:1053 (/home/dan/Source/perl6/install/share/nqp/lib/NQPHLL.moarvm:panic)
^^^ just removing it
Xliff MasterDuke: Oh, wow. 10:23
raydiak heh, fair enough 10:24
dakkar the bug is not that change precedence/assoc fails, is that it fails *silently* 10:26
it *must* fail
lizmat and all of that would be different with the RakuAST branch 10:27
dakkar m: multi sub infix:<☞>(Int $a, Int $b) is assoc<left> { return $b }; multi sub infix:<☞>(Str $a, Str $b) is assoc<right> { return $b }; sub foo($a,$b,$c) { return $a☞$b☞$c }; say foo(1,2,3); 10:27
Xliff Where can I find a list of CORE grammar rules? 10:27
camelia 3
dakkar m: multi sub infix:<☞>(Str $a, Str $b) is assoc<right> { return $b }; multi sub infix:<☞>(Int $a, Int $b) is assoc<left> { return $b }; sub foo($a,$b,$c) { return $a☞$b☞$c }; say foo(1,2,3);
camelia 3
dakkar uh… that worked differently on my machine
lizmat it should probably complain about assigning associativity to candidates, rather than the proto 10:28
Xliff lizmat++: I expect RakuAST will solve a lot of things and give us new bugs we didn't expect.
lizmat I'm not saying it would solve this
dakkar lizmat: I agree 10:29
raydiak Xliff: the core grammar is github.com/rakudo/rakudo/blob/mast...rammar.nqp 10:30
dakkar lizmat: AIUI, having candidates with different assoc/precedence should just be prohibited, because it can't be made to work 10:31
lizmat any assoc trait on a candidate is just ignored, apparently
compar:
m: multi sub infix:<foo>(\a,\b) is assoc<left> { "foo" }; dd &infix:<foo>.prec
MasterDuke couldn't it work if they have non-overlapping types?
camelia Hash % = {}
lizmat m: proto sub infix:<foo>(|) is assoc<left> {*}; multi sub infix:<foo>(\a,\b) { "foo" }; dd &infix:<foo>.prec
camelia Hash element = {:assoc("left"), :prec("t=")}
dakkar MasterDuke: no, because associativity is a parse-time thing, and at parse-time you (almost)never have enough typing information 10:32
lizmat so you're telling the candidate something, but nobody's listening :-)
dakkar not exactly… 10:33
m: multi sub infix:<☞>(Int $a, Int $b) is assoc<left> { return $a+$b*1000 };multi sub infix:<☞>(Str $a, Str $b) is assoc<right> { return "($a,$b)" };sub foo($a,$b,$c) { return $a☞$b☞$c };say foo(1,2,3);
camelia 5001
dakkar m: multi sub infix:<☞>(Str $a, Str $b) is assoc<right> { return "($a,$b)" };multi sub infix:<☞>(Int $a, Int $b) is assoc<left> { return $a+$b*1000 };sub foo($a,$b,$c) { return $a☞$b☞$c };say foo(1,2,3);
camelia 3002001
dakkar notice that the associativity changed
it's taken from the first candidate seen
lizmat hmmm...
worth an issue, I'd say, if there isn't one already 10:34
dakkar there is: github.com/rakudo/rakudo/issues/1237
although it may be reworded to more explicitly point out that the problem is the "silently", not the "fails"
declaring candidates with different assoc/prec should be a compile-time erorr 10:35
lizmat agree 10:36
raydiak can the precedence of the proto be changed?
dakkar maybe in a slang
lizmat I guess you could, but it will only affect code compiled *after* that change 10:37
so you'd need to do that at compile time, and it wouldn't affect any code compiled *before* that change
dakkar isn't "I want this to be parsed different than normal raku" exactly what slangs are for? 10:38
lizmat it is
but the question was about core ops, no ?
raydiak yes he wanted to change the precedence of infix:<*> 10:42
Xliff lizmat: It is as you say. Your understanding is along the lines of what I need.
lizmat: glot.io/snippets/fyxgoslq4r 10:43
In that example, the right multi is dispatched, but the operator precedence is unchanged. 10:45
raydiak I have to ask because nobody has yet...why? 10:51
Xliff Because that's what I need. 10:55
Xliff I dislike it when that question comes up, because then someone can say "why do it that way" or "what's the point" 10:56
And then stop answering.
raydiak well that's why I thought of everything I could suggest *before* asking :) either way I'm gonna stop answering in the next several minutes, have to try to get a few hours of sleep soon 10:58
Xliff Now that is an acceptable reason to stop answering... 10:59
Xliff :) 10:59
Xliff Again, thanks for your help. 10:59
raydiak I mean at this point, you're down to writing a slang, parsing the whole expression with your own grammar, or doing whatever you're doing some other way anyway 11:00
looks like dakkar and lizmat were the insightful ones here, but glad I could do...whatever I did :D
Xliff radiak: Yeah. I am going the grammar route, with.... not much luck. 11:02
glot.io/snippets/fyxh7lm58f
Xliff I can't figure out why that last expression isn't getting parsed. 11:03
raydiak Grammar::Tracer is really helpful for deubgging and optimizing grammars 11:07
Xliff Yes, but it won't handle all cases
raydiak what doesn't it handle? 11:08
Xliff I'm to tired to remember. 11:08
I need sleep, too!
raydiak I'm sure it should work for what you pasted, I used it for all of Math::Symbolic 11:09
Xliff Will check later today, then. Thanks. 11:10
raydiak: Ah. The situation where it the grammar can't get a hold of a starting place. 11:12
raydiak yw, good luck. bed and hopefully sleep for me. lizmat if you see this let me know about my question at 9:21:52, there are many irregularities in the html and I don't know if I should be reporting them in one big issue, a pile of small issues, or not at all 11:14
lizmat raydiak: please hold off until we got real UI people involved (sena_kun is working with me on that) 11:15
lizmat I never got much beyond HTML 0.9 :-) 11:16
raydiak heh got it 11:17
MasterDuke Xliff: i think the problem is you can't have an expression on the left in your grammar 11:20
*a parenthesized expression 11:21
Xliff MasterDuke: Yep. Figured that out. Still trying to work out the best solution. 11:23
MasterDuke moritz might be around 11:24
moritz_ hm?
MasterDuke from Xliff, glot.io/snippets/fyxh7lm58f "I can't figure out why that last expression isn't getting parsed." 11:25
moritz_ MasterDuke: well, you figured it out already 11:26
MasterDuke heh. the problem, not a solution 11:27
moritz_ my go-to solution is another layer of indirection 11:29
perlpunks.de/paste/show/60acdfac.6b20.384
that's what I use in the book 11:30
the gist is that an expression is <term> <operator> <term>, and term can be a <value> or '(' <expression> ')' 11:31
the rest (using multi regexes) is just sugar
Xliff moritz_++ # Thanks! 12:04
holyghost I finished the my Solstice with just floors :-) 13:05
s/the//
[Coke] is it possile that running the REPL for the first time ends up precompiling something? 15:12
*possible
Finding that the REPL on windows is very slow to start (2021.04)
ah. it's not doing anything in the background, just hanging. :( 15:13
ugexe you could run `RAKUDO_MODULE_DEBUG=1 raku` to find out
[Coke] ah: under 'cmd', it launches immediately. under 'git bash', it hangs. 15:14
lizmat it shouldn't precompile anythinkg 15:15
then it probably cannot read STDIN in that case ?
[Coke] lizmat: tried cmd/powershell; even under the right codepage (65001), the welcome to message isn't rendering. Guessing we'd need some kind of font fallback mechanism? 15:22
lizmat so you're saying the rendering of the welcome message is what's blocking ? 15:23
[Coke] no. separate issue 15:24
... as far as I know
nine But...if it's unable to output anything, how do you know that it's actually hanging and not just waiting for your input? 15:31
[Coke] I don't know that it can't output anything? 15:38
there are 2 issues here; one is running raku repl under git bash, the other is displaying the repl announcement where it does work.
ugexe i guess it doesnt suprise me that it doesnt work under git bash, since that is probably a more cygwin toolchain like setup and you likely used VS toolchain to build rakudo 15:39
[Coke] happy to test while I have the windows box up if there's anything else I can run.
I did use VS. note that raku works fine in scripts, just not in REPL there. 15:40
ugexe raku -e 'say $*SPEC.raku' 15:41
[Coke] (could very well be DIHWIDT)
ugexe what does that say in git bash by chance
[Coke] IO::Spec::Win32
renormalist raku.org/ still talks about freenode for IRC. 15:42
ugexe the repl worked for me on windows using 2020.04. building 2021.05 now 15:43
[Coke] ugexe: again, works fine here in cmd & powershell.
ugexe ah so the issue in cmd is just the jumbled text? 15:44
renormalist rakudo.org/ also has a link to freenode near the bottom
[Coke] ugexe: aye 15:45
ugexe yeah thats been that way for a bit. i argued against it but im not a lawyer
[Coke] which is very likely just a font issue; tried various system fonts, tried source code pro, nada. I think on the mac there's a fallback font for unicode, not sure that exists on windows.
well, the message is useless on windows at the moment, at least for me. I opened a ticket if someone wants to use that to argue we should at least default to plain text. 15:46
ugexe well asking the average window user to change their terminal settings is a pretty big ask considering i dont think any other language does so
[Coke] I think it makes sense to get to the unicode features of the language; not to see the welcome message. 15:47
ugexe aye
lizmat renormalist: thanks for the headsup
renormalist: I think we have all the changes done, it's now a matter of deploying :-) 15:48
renormalist lizmat: cool, thanks
[Coke] ugexe: I found one font where instead of "cant display glyph", you get whitespace (just blanks). "welcome to TM" 15:53
ugexe ive always just gotten "Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.05." 15:59
tonyo asking someone to change their font is just as bad 16:18
andinus do old versions of modules stay forever on fez? 16:58
mine is listed as "xyz:ver<0.1.1>", "xyz:ver<0.1.2>" and search for it on modules.raku.org returns 3 results (1 - CPAN entry, 0.1.1 fez, 0.1.2 fez entry) 17:00
how do i make it show only the 0.1.2 entry and not pollute the results?
tonyo andinus: yes they do 17:11
tonyo what do you mean by not pollute? it'd be up to the search or zef to only show the highest ver 17:12
up to search meaning up to your search term, eg `zef search xyz:ver<0.1.2>` 17:13
andinus by pollute i meant that the number beside tags (on modules.raku.org) increments by 1 for each version i push 17:22
[Coke] might be nice if default search showed latest stable and not everything, but allowed -v to show all. 17:27
(assuming we have the concept of a stable or recommended, not sure we do)
tonyo i thought zef only showed the highest version 17:38
ugexe: ^
tonyo andinus: what is the name of the module? 17:38
antlia?
ugexe zef will show all of them if you do `search` and the highest if you do `info` without any version
the problem they are talking about is how modules.raku.org groups (or rather doesnt group) distributions 17:39
tonyo d'oh 17:40
daimon tyil, lizmat, nine: in the mass migration from freenode my primary concern was making sure my channels and nicknames remained owned by me, as an extension of this I also tried to register nicknames and channels for the communities I am involved in, as of such I own the nicknames 'perl','purl','raku','erlang' and 'csharp'; I obviously reserved 'raku' for yourselfs - if you have a use for that nickname drop me a message if you are +F in this channel it will be 17:41
transferred to you immediately; if not then well its safe for whenever (if you ever) require it
tonyo i reserved daimon1 17:44
daimon :)
daimon my actual main nickname is daemon but it causes havok in accidental highlights 17:45
andinus tonyo: yes i was talking about antlia 17:46
stoned75 commit: releases my $a = <42>; my Str $s = $a; my Int $i = $a; say ($s.WHAT, $i.WHAT); 18:07
committable6 stoned75, ¦releases (54 commits): «((IntStr) (IntStr))␤» 18:08
ptc m: say "hullo libera raku!" 20:18
camelia hullo libera raku!
lichtkind us here the organizer of raku conf? 20:44
what kind of talk do you want?
raydiak we've moved to irc.libera.chat, you might have more luck there. it's also near our quiet time, as much of the community is in europe where it's getting late. if you wanted to try e-mail or other contact methods, they're listed on conf.raku.org/contacts 21:03
in general though, I'd expect pretty much any talk related to the Raku language to be welcome 21:04
lichtkind raydiak: thank you 21:23
raydiak you're welcome :) 21:27
lichtkind raydiak: but channel there is 6667 21:31
raydiak yes 6667 for unecrypted connections, 6697 for TLS 21:36
actually, looks like there's more ports than that. see libera.chat/guides/connect 21:37
lichtkind raydiak: yes i mispelled libera thank im there now 21:41
raydiak cool
moon-child m: .say for 5 22:40
camelia 5
lichtkind raydiak: well the topic i would choose i already talked about at yapc 22:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!