🦋 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.
Geth ecosystem: stuart-little++ created pull request #593:
Add Data::Tree to ecosystem		 00:36
xinming m: 00:37
class C is Supplier { has @.sources; submethod BUILD (:@!sources) { @!sources.raku.say; } } C.new(:sources[1,2,3]);
m: class C is Supplier { has @.sources; submethod BUILD (:@!sources) { @!sources.raku.say; } } C.new(:sources[1,2,3]);
camelia 5===SORRY!5=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> 3D (:@!sources) { @!sources.raku.say; } }7⏏5 C.new(:sources[1,2,3]);
expecting any of:
infix
…
xinming m: class C is Supplier { has @.sources; submethod BUILD (:@!sources) { @!sources.raku.say; } }; C.new(:sources[1,2,3]);
camelia []
xinming m: class A { }; class B is A { has @.sources; submethod BUILD (:@!sources) { @!sources.raku.say; }; B.new(:sources[1,2]); 00:38
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3urces.raku.say; }; B.new(:sources[1,2]);7⏏5<EOL>
xinming m: class A { }; class B is A { has @.sources; submethod BUILD (:@!sources) { @!sources.raku.say; } }; B.new(:sources[1,2]);
camelia [1, 2]
xinming So, In these 2 examples, why will the class inherited from Supplier doesn't receive the @!sources, but classes we created manually work, is this a bug? 00:39
guifa codesections: that’s effectively recreating the old wantarray from the perl era, just on steroids :-) 00:44
xinming: not all classes will call BUILD / TWEAK for subclasses. I forget exactly why but I remember having some issues with that when trying to subclass Hash 00:47
Err, no, that’s with it not being called. Yours is definitely being called 00:48
xinming yea, seems args are removed when calling subclasses. 00:49
so, I'd think it's a bug.
guifa m: class C is Supplier { has @.sources; submethod BUILD (|c) { c.raku.say; } }; C.new(:sources[1,2,3]);
camelia \(:taplist(Supplier::TapList.new))
xinming Ok, so we know the reason.
guifa should be an easy fix then. /me checks out the code 00:50
github.com/rakudo/rakudo/blob/168d...er.pm6#L99 00:51
I suppose that should be changed to something like
xinming guifa: another question 00:52
guifa: dpaste.org/KHKW#L16,19,20,21
Yea, I just figured it's a bug 00:53
my latter question is, do we really need the `$!promise = ` part?
method new (\c) { self.bless(taplist => ..., |c) } 00:54
But I'm not sure wether it's a bug in Supplier code or designed to be like this
guifa method new (:$taplist = TapList.new, |c) { self.bless: :$taplist, |c } or something similar 00:55
xinming guifa: could you please clarify the other questoin? 00:57
guifa I admit, I don’t play around with asynch code as much. Does the react block continue working even after the BUILD method has completed? If so, and if you don’t really care about getting any other information (like when —if ever — the react block finishes) then it’s probably not necessary 01:00
xinming The reason I'm curious is, it worked without storing the promise into a var, so I'm afraid of it'll be gc'ed in the long run, or it'll probably be mem-leak in long run, that's why I got confused. 01:04
guifa Alas, GC/mem management is also not a forté of mine 01:06
xinming Ok, thx anyway, will trouble someone else. 01:13
:-)
guifa: do you think the Supplier thing is a bug?
if so, I'll report it, or write patch?
guifa xinming: it *might* be. I think the problem is that the taplist uses a private class, so the question would be what to do when someone passes in a :taplist argument 01:35
Probably Supplier needs its own BUILD method that sets that property independently (which is effectively what it does). I’d submit a ticket, and see what someone like jnthn thinks is the better fix to allow easier subclasses 01:36
xinming guifa++ 01:50
holly_ Hi Xliff, still busy on gtk ? 03:44
holly_ is writing the hollybot 03:54
Geth doc: a2e8cada00 | (Stoned Elipot)++ (committed by Juan Julián Merelo Guervós) | doc/Type/Num.pod6
Document Num.Str
 05:38
linkable6 Link: docs.raku.org/type/Num
Geth ecosystem/master: 4 commits pushed by chirvasitua++, (Juan Julián Merelo Guervós)++ 09:06
xinming_ in an object, we have `start react { ... }` block, and that async event handler worked fine, but I'm curious will this cause memory leak? 10:13
IIRC, I thought that `start react { ... }` returns a promise, when that promise go out of scope, it should be gc'ed 10:14
codesections I haven't done a whole lot in that area, but that sounds correct to me 10:16
m: my $p = start { react { }}; say $p; say $p.status
camelia Promise.new(scheduler => ThreadPoolScheduler.new(initial_threads => 0, max_threads => 64, uncaught_handler => Callable), status => PromiseStatus::Kept)
Kept
xinming_ codesections: something like. 10:30
m: sub t () { start react { }; "hello"; }; t().say; 10:31
camelia hello
xinming_ You see, the `start react { };` here is not stored in var, but it will work in background, So I'm quite curious wether it'll cause mem-leak, or in the long run, the code will be gc'ed, and cause unexpected behavior. 10:32
moon-child it will be gc'd 10:35
whether you store it in a variable or not has no bearing on that 10:36
(actually, storing it in a variable can only cause it to _not_ be GCed)
xinming_ moon-child: then, the code in `start react { }` will result unexpected behavior, so we shouldn't do this, right?
We store the `start react { }` in a block somewhere 10:37
moon-child start react {} is fine 10:41
nothing wrong with it
Voldenet `start react {}` is a fine way to mess up error handling 10:43
but otherwise it will work 10:45
Voldenet `start react {}` will cause memleaks in cases like `my \s = Supplier.new; start react { whenever s.Supply {} };` 10:51
codesections How do type captures for return values work? I expected the below to compile: 10:54
m: sub f(::T $a --> T) { $a } f 42
camelia 5===SORRY!5=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> 3sub f(::T $a --> T) { $a }7⏏5 f 42
expecting any of:
infix
infix stopper
statemen…
codesections m: sub f(::T $a --> T) { $a }; f 42
camelia Type check failed for return value; expected T but got Int (42)
in sub f at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat I think there's an issue for this already, I sorta expect this to be fixed in the RakuAST branch 10:55
codesections lizmat++ Thanks, I thought I was just missing something
lizmat actually, I think the error message is also wrong, or it could be an indication of the issue 10:56
xinming_ Voldenet: if it's not referenced, how will raku know the `start react { }` thing is still in "use"? is `start react { }` block won't be removed? 10:59
lizmat xinming_: please realize that start react whenever and friends are just syntactic sugar for setting up a bunch of internal objects using UPPERCASE is implementation-detail subs and setting up various dynamic variables 11:03
pretty sure there's something in there that will keep things alive even though from the syntax you might think it doesn't 11:04
ctilmes alpine linux 3.14.0 released, includes rakudo 2021.05, just 'apk add rakudo' 12:23
El_Che ctilmes++ 12:24
lizmat whee! :-) 12:33
tyil nice 12:53
xinming_ lizmat: I understand that, that's why I feel, if we have bunch of internal objects out there, Does it mean the memory will leak over time? as I'm trying to do something that may dynamically call `start react { ... }` over time. 13:09
lizmat it shouldn't :-) 13:22
moritz there will be memory and CPU used for every task you start with 'start'. Do these tasks terminate, eventually?
xinming_ moritz: It will, the react will finally have `done();` be called, I just got worried about without var, the promise will be gc'ed, and so will react block, then in the long run, the react will stop working. 13:37
well, I'll use it anyway, ram is cheap.
Xliff m: my $a = Mu; say "Hi" unless $a =:= Mu 15:45
camelia Hi
Xliff Hun?!?
m: my $a = Mu; say "Hi" unless Mu =:= $a
camelia Hi
Xliff m: my $a = Mu; say "Hi" unless Mu === $a
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
cnx what is =:=? 15:46
Xliff container equality
cnx thanks
Xliff Which... in the case of Mu, doesn't seem to work.
m: my $a = Any; say $a =:= Any 15:47
camelia False
Xliff m: my $a = Any; say ($a =:= Any)
camelia False
Xliff m: my $a = Any; say ($a === Any)
camelia True
Xliff m: my $a = Mu; say ($a === Mu)
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
codesections m: my $a := Mu; say $a =:= Mu; # Is it just the Scalar getting in the way? 15:49
camelia True
codesections the docs say "Returns True if both arguments are _bound_ to the same container" (docs.raku.org/routine/=:=), so I think that's it 15:51
dakkar codesections: I guess so 15:52
m: my \a := Mu; say a =:= Mu 15:53
camelia True
dakkar then again, it said "true" in your case as well…
m: my \a := Mu; say a =:= Int
camelia False
dakkar (just to check…)
codesections (fyi, `my \a := Mu` is redundant – \a binds by default, so `my \a = Mu` is the same thing. But $a assigns by default, so you need the := bind operator to bind) 15:54
m: my \a = Mu; say a =:= Mu 15:55
camelia True
dakkar thank you! that's a bit of raku I haven't needed yet, so I'm not familiar
ok, now I've actually read the whole conversation… 16:04
the error message for `== Mu` is LTA, though
m: 1==Mu 16:05
camelia WARNINGS for <tmp>:
Useless use of "==" in expression "1==Mu" in sink context (line 1)
Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
dakkar m: say 1==Mu
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
dakkar m: say 1===Mu
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
dakkar (I know why it does that, still LTA)
codesections The fix for that would be pretty easy, if you're interested: just add a multi infix:<===>(Mu \a, Mu \b) candidate in ./core.c/Mu.pm6 that dies with an error (similar to how List.push does). I'm sure a PR like that would be appreciated :D 16:08
Altreus now it's getting to the time I'm feeling overextended today :/ 16:13
moritz it also kills autothreading
Altreus might try a nap and see how I feel
dakkar moritz: I suspected that
(also, shouldn't Mu===Mu be True?)
codesections even if it doesn't match?
moritz autothreading works as a fallback to regular dispatch 16:16
since Junction ~~ Mu, a dispatch to (Mu, Mu) works, and so there is no fallback
m: multi a($x, $y) { say "($x, $y)" }; a(any(1, 2), 5) 16:17
camelia (1, 5)
(2, 5)
codesections oh, I didn't realize that. Hmm... nvm, not as easy as I was thinking. Sorry about that!
moritz m: multi a($x, $y) { say "($x, $y)" }; multi a(Mu, Mu) { say "moooh"}; a(any(1, 2), 5)
camelia moooh
dakkar moritz: so there's no decent way to have 1==Mu and 1===Mu be False, and Mu===Mu be True? (plus all the other relational ops) 16:18
(short of special-casing in the dispatcher)
moritz not if you want === to autothread 16:20
(I still think that === shouldn't autothread, as I thought when we first discussed this. Sadly I couldn't convince Larry)
dakkar I can argue it both ways… 16:21
this is one case where a *rakudo* (not raku) documentation suite would be useful 16:24
so we could document this apparent weirdness
(which, technically, is a side-effect of the way rakudo works, not exactly required/implied by the raku spec)
moritz === not autothreading and the way the dispatcher works are very much part of raku, and tested to the death in roast 16:26
(at least that was the case back in the days...)
dakkar yes 16:27
I mean, 1===Mu throwing instead of returning False, is *probably* not in roast ☺
(and it could be made to return False, it's just a bad idea to do so in rakudo's dispatcher, AIUI) 16:28
(yes, that "just" is doing a lot of work there) 16:29
anyway, that's the end of my workday, I'm disconnecting now 16:31
[Coke] o/ 16:51
codesections \o 16:52
guifa o/ 16:54
\o/ (o) (o( /o\ 16:55
lizmat: any tips on making nqp code not look … ugly as sin?
codesections guifa: I'm not liz (obviously!) but I found that thinking of it as a Lisp helped a bit 16:58
guifa doesn’t have any lisp experience haha
guifa Do you just do lots of extra line breaks with indentation to make relations easier? 17:00
codesections yeah, and with more horizontal alignment between expressions. Somewhat like github.com/xuchunyang/elisp-demos/...sequencep, though not 100% 17:03
guifa Is there any clean way to mimic a
while my $foo = some-call { … } ? 17:04
[Coke] (rakudo docs) not sure what JJ's thoughts are, but it seems reasonable to me to have [rakudo] only blocks in the docs to describe things that rakudo is doing that may not be "canon", but are nonetheless expected. I'm sure there are some ad hoc ones scattered through the docs already 17:06
but if there's a need, put together a list on a wiki page on the rakudo/rakudo repo to start. 17:07
guifa Actually, the more I’m working on this, the more I’m curious just how complex I should go with DateTime formatting 17:09
codesections m: use nqp; my @a = ^5; nqp::while(nqp::stmts((my $foo = @a.pop)), say "foo was $foo") # Does something like this work?
camelia foo was 4
foo was 3
foo was 2
foo was 1
guifa codesections: huh, I swear I tried that last night and it didn’t work. But in my defense it was late 17:10
codesections (That's a hybrid of nqp and Raku -- in a pure nqp setting, it'd be a bit more verbose)
guifa The other thing I miss is if chaining / given/when 17:12
I’ve got a value that can be anything from, say, 0-8, and I’ve tried doing sequential checks with returns, and also divide and conquer style if < 4, if < 2, if == 0, and that just gets ugly fast, even if more optimal. 17:15
I thought about just making an array of subs to act as a jump table of sorts, but I dunno, maybe that’s overly complicating it 17:16
codesections Yeah, I've noticed that a lot of the nqp in Rakudo uses nested ternary operators, though ymmv on how readable that is (and I think there might have been a perf. reason for that as well?) 17:18
e.g., github.com/rakudo/rakudo/blob/mast...#L333-L344 17:19
guifa Ah that is a good bit more readable
I should have thought of that
codesections well, I know some people hate nested ternaries, but I agree that it's easier to follow here 17:22
guifa One GNU variant also has an interesting modifier for formatting: flip casing. 17:23
ugexe ternary doesnt have to create a new lexical scope so id expect it to be faster than any construct using blocks
guifa ugexe++ makes sense, I know that’s one of the reason’s that postfix loops are a smidgen faster, right? 17:24
ugexe i cant say for sure thats why, but i would expect it to contribute yeah 17:25
guifa also F whoever in Gnu thought it would be a good idea for a flipped-case modifier. 17:26
codesections I admit that I've used it 17:28
guifa Really?
guifa is legit interested, can’t think of when Foo -> fOO makes much sense
ugexe easily create namespace collisions on case insensitive file systems 17:30
codesections my current desktop displays the date with 17:32
m: say qx{date '+%a, %b %e %l:%M %#Z'}
camelia Wed, Jun 16 7:32 cest
lucs codesections: I don't indent those subsequent ternaries; it would like be indenting each new "elsif" in a series of such.
codesections (actually, with the lowercase timezone flush against the hour) 17:33
guifa codesections: yeah, that’s actually where it specifies the use. But that makes more sense to have a lowercase modifier, than a flip case modifier
codesections yeah, that's fair. Someone over designed it -- I bet the goal was to avoid having two modifiers (for lower and upper), but they needlessly introduced state into _formatting_ 17:34
ugexe maybe useful for a naive almost-right password detector. i think facebook uses something similar where you can enter your password but slightly wrong and it will work
guifa Well, there *is* an upper case one though :-) 17:35
codesections wait, really? Ok, that's just bonkers
guifa m: say qx{date ‘+%^a, %b %e %l:%M %#Z'}
camelia /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
ugexe i think it was for entering passwords using T9 or some such
guifa ugexe: yikes, does that still exist? That sounds like it really opens up a potential space for guessing passwords
guifa m: say qx{date '+%a, %^b' } 17:37
camelia Wed, JUN
guifa m: say qx{date '+%#a, %^b' }
camelia WED, JUN
ugexe at facebook im not sure... T9 has sort of gone away. but many banking systems also did this (they would just store the T9 number of the password, so multiple passwords would work) but those are legacy systems and many might still do this crap
i.e. if your password was just "a" then "a" "b" or "c" would all work 17:38
guifa codesections: ^^ what's worse is that there's a lot of format commands that are semi-special cased, and it looks like # is one of them. I might just say screw it, # is lower case, and make my life easier. It's an extension of the standard, so I suppose I'm not obligaited to do it like everyone else if their way is stupid :-)
codesections wow. So, despite all that complexity, there isn't a way to get 'jun' as the output! 17:41
guifa Yup. Kind of crazy. I think just using # for lc is probably best and just document it as a difference with GNU 17:45
Altreus ok plan b since today is crap - gonna do the stream tomorrow instead and hopefully I'll feel better 18:05
Gives me a bit more time to set this pesky environment up too 18:06
holly_ Altreus : take care
Altreus :) 18:07
melezhik Colorizable started to produce a lot of warning under latest Rakudo version - gitlab.com/uzluisf/raku-colorized/-/issues/4 I wonder if this relates to Rakudo itself? 18:26
MasterDuke the warning is correct, doing .contains on a map is risky, gitlab.com/uzluisf/raku-colorized/...kumod#L154 and gitlab.com/uzluisf/raku-colorized/...kumod#L160 should be changed 18:32
melezhik yeah, this is for the modules's author, I just use it ... thanks 18:39
melezhik I golfed it - raku -e 'use Colorizable; my $s = "hello" but Colorizable; sat $s.yellow.bold ' 18:58
it happens only for this style of method invocation 18:59
but not for `raku -e 'use Colorizable; my $s = "hello" but Colorizable; say $s.colorize(:fg(yellow), :mo(bold)) '`
SmokeMachine m: my $a = Mu; my $b := Mu; my \c = Mu; say $a =:= Mu; say $b =:= Mu; say c =:= Mu; say Mu =:= Mu 20:10
camelia False
True
True
True
Geth doc: 33c390bbcc | (Stoned Elipot)++ | doc/Type/Real.pod6
Document Real.Str
 20:18
linkable6 Link: docs.raku.org/type/Real

Powered by Cro and the Raku® Programming Language.

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

Thank you!