🦋 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.
00:02 reportable6 left 00:06 reportable6 joined
Geth ecosystem: stuart-little++ created pull request #593:
Add Data::Tree to ecosystem		 00:36
00:37 pierrot_ is now known as pierrot
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
01:09 holly_ left 01:12 holyghost joined 01:13 holly_ joined
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
01:45 GoneDomattps is now known as domattps
xinming guifa++ 01:50
01:56 holly_ left, holly_ joined 01:59 tejr left 02:02 tejr joined 02:07 holly_ left 02:11 japhb joined 02:23 frost joined 02:28 frost left 02:39 frost joined 02:40 frost left, frost joined, frost left 02:43 frost joined 02:52 domattps is now known as GoneDomattps 02:57 GoneDomattps is now known as domattps 03:21 [1]holyghost joined, [1]holyghost is now known as holly_ 03:25 Xliff joined
holly_ Hi Xliff, still busy on gtk ? 03:44
holly_ is writing the hollybot 03:54
03:57 RandalSchwartz left 04:27 abraxxa left 04:32 vrurg joined 04:34 vrurg_ left 04:36 holyghost left 04:55 Xliff left 05:24 nebuchadnezzar joined, domattps is now known as GoneDomattps 05:29 GoneDomattps is now known as domattps
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
05:39 domattps is now known as GoneDomattps 05:41 Doc_Holliwood joined 05:45 tejr left, tejr joined 06:02 reportable6 left 06:05 reportable6 joined 06:06 xinming left, xinming joined 06:10 holly_ left 06:30 xinming left, xinming joined 06:38 ufobat_ joined 07:03 abraxxa joined 07:08 abraxxa left, abraxxa joined 07:20 Doc_Holliwood left 07:21 GreaseMonkey left 07:25 greaser|q joined 07:33 ufobat_ is now known as ufobat 07:51 Sgeo left 07:57 dakkar joined 07:59 holyghost joined, dakkar left, dakkar joined 08:11 synthmeat left 08:13 synthmeat joined 08:40 linkable6 left 08:42 linkable6 joined 08:45 greaser|q left, greaser|q joined 08:46 greaser|q is now known as GreaseMonkey 09:01 kylese joined
Geth ecosystem/master: 4 commits pushed by chirvasitua++, (Juan Julián Merelo Guervós)++ 09:06
09:11 gordonfish- joined, gordonfish left 09:15 dogbert17 joined 09:20 squashable6 left 09:21 squashable6 joined 09:22 abraxxa left 09:27 abraxxa joined 09:31 juanfra left, RakuIRCLogger joined, demostanis[m] left 09:32 abraxxa left 09:33 juanfra joined 09:38 demostanis[m] joined, AlexDaniel joined, cnx joined, tyil[m] joined, ComplYue[m] joined, CIAvash joined 10:10 xinming_ joined 10:12 xinming left
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
10:47 Doc_Holliwood joined
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
11:02 tejr left, tejr joined
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
11:04 sono left 11:05 abraxxa joined 11:10 abraxxa left, abraxxa joined 11:20 squashable6 left 11:21 squashable6 joined 11:41 kylese left 11:43 esh left 11:45 esh joined, Ulti_ is now known as Ulti 12:02 reportable6 left 12:03 reportable6 joined 12:17 yewscion_ left 12:21 ctilmes joined
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
12:51 kakadzhun joined
tyil nice 12:53
12:58 Doc_Holliwould joined 13:00 RandalSchwartz joined 13:02 Doc_Holliwood left
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?
13:33 lizmat left 13:34 lizmat joined
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.
13:45 Guest81 joined 13:50 jrjsmrtn_ joined 13:52 Guest81 left 13:54 gordonfish- is now known as gordonfish 14:02 jrjsmrtn_ is now known as _jrjsmrtn 14:04 Henry151 left 14:09 Henry151 joined 14:10 Henry151 left 14:11 Henry151 joined 14:15 GoneDomattps is now known as domattps 14:29 cbk joined 14:32 Sgeo joined 14:34 Xliff joined 14:39 ufobat_ joined 14:42 ufobat left 14:51 Henry151 left 14:52 Henry151 joined 14:53 Henry151 left 14:55 Henry151 joined 14:56 morayj joined 14:59 Henry151 left, Henry151 joined, Henry151 left 15:03 Henry151 joined 15:15 b2gills left 15:19 kakadzhun left 15:28 swaggboi left
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
15:49 Doc_Holliwould left
codesections m: my $a := Mu; say $a =:= Mu; # Is it just the Scalar getting in the way? 15:49
camelia True
15:50 Xliff left, swaggboi joined
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)
16:05 holly_ joined
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
16:36 dakkar left, swaggboi left 16:50 swaggboi joined
[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
16:59 ufobat_ left
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
17:05 morayj left 17:06 morayj joined, stoned75 left
[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
17:36 holyghost left
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 :-)
17:39 swaggboi left
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
17:48 frost left 17:50 swaggboi joined 17:51 stoned75 joined 18:02 holyghost joined, reportable6 left 18:04 reportable6 joined
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
18:23 eseyman left 18:25 melezhik joined
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
18:27 Doc_Holliwood joined 18:29 eseyman joined
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
18:43 stoned75 left
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)) '`
19:22 lgtaube left 19:25 stoned75 joined 19:38 lgtaube joined 19:41 holly_ left 19:58 holyghost left 20:05 ctilmes left 20:08 stoned75 left, stoned75 joined
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
20:13 stoned75_ joined, stoned75 left, stoned75_ is now known as stoned75 20:15 sono joined
Geth doc: 33c390bbcc | (Stoned Elipot)++ | doc/Type/Real.pod6
Document Real.Str
 20:18
linkable6 Link: docs.raku.org/type/Real
20:53 cbk left 21:06 morayj left 21:46 lgtaube left, lgtaube joined 22:09 abraxxa left 22:30 holly_ joined 22:31 Doc_Holliwould joined 22:33 Doc_Holliwood left 22:38 tyilanmenyn joined 22:39 tyil left 22:41 tyilanmenyn is now known as tyil 23:05 Doc_Holliwould left 23:55 Util_ 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!