🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left, reportable6 joined 01:00 linkable6 left, evalable6 left 01:01 evalable6 joined, linkable6 joined
MasterDuke timo1: i see some extra `p6typecheckrv` in the uint version, but otherwise essentially the same. and same runtime, plus it passes a spectest 01:56
very nice
but it looks like maybe it's not doing everything, since AlexDaniel's example script with uints is still showing a `p6forstmt` instead of the while 02:00
heh, yep. replacing the literal in just the for loop with a variable slows it back down for uints even with your patch, but not for ints. e.g., `my uint $sum = 0; my uint $max = 100_000_000; for ^$max -> uint $i { $sum += $i }; say now - INIT now; say $sum;` 02:08
fyi, this has all been on moarvm master, not my add_*_u_ops branch 02:11
03:11 MasterDuke left 03:48 MasterDuke joined 04:02 MasterDuke left, djinni` left, codesections left, japhb left, ab5tract left, sjn left, quotable6 left, squashable6 left, nativecallable6 left, committable6 left, unicodable6 left, discord-raku-bot left, zostay left, patrickb left, summerisle left, camelia left, maettu left, leont left, SmokeMachine left 04:03 MasterDuke joined, patrickb joined, summerisle joined, djinni` joined, ab5tract joined, codesections joined, quotable6 joined, squashable6 joined, nativecallable6 joined, committable6 joined, unicodable6 joined, japhb joined, sjn joined, camelia joined, discord-raku-bot joined, maettu joined, leont joined, SmokeMachine joined, zostay joined, nine left, nebuchadnezzar left, |Tux| left, elcaro left, rba left 04:04 nine joined, nebuchadnezzar joined, |Tux| joined, elcaro joined, rba joined 04:09 kawaii left, Voldenet left, ugexe left, kawaii joined, Voldenet joined, ugexe joined 04:10 tonyo left, ugexe joined, ilogger2 left, normietotechie[m left, sivoais left, samebchase left, JRaspass left, [Tux] left, tbrowder left, heartburn left, timo1 left, evalable6 left, reportable6 left, jdv left, sourceable6 left, bisectable6 left, releasable6 left, bloatable6 left, statisfiable6 left, shareable6 left, benchable6 left, tellable6 left 04:11 gfldex left, samcv left, bartolin_ left, jjatria left, JRaspass joined, sivoais joined, samebchase joined, tonyo joined, ilogger2 joined, samebchase left, [Tux] joined, tbrowder joined, linkable6 left, notable6 left, greppable6 left, coverable6 left, kjp left, timo1 joined, heartburn joined, samebchase joined 04:12 linkable6 joined, notable6 joined, greppable6 joined, coverable6 joined, kjp joined 04:17 evalable6 joined, reportable6 joined, jdv joined, sourceable6 joined, bisectable6 joined, releasable6 joined, bloatable6 joined, statisfiable6 joined, shareable6 joined, benchable6 joined, tellable6 joined, gfldex joined, samcv joined, bartolin_ joined, jjatria joined 04:18 squashable6 left 04:20 evalable6 left, reportable6 left, jdv left, sourceable6 left, bisectable6 left, releasable6 left, bloatable6 left, statisfiable6 left, shareable6 left, benchable6 left, tellable6 left, gfldex left, samcv left, bartolin_ left, jjatria left, linkable6 left, notable6 left, greppable6 left, coverable6 left, kjp left, [Tux] left, tbrowder left, heartburn left, timo1 left 04:21 squashable6 joined, JRaspass left, sivoais left, tonyo left, ilogger2 left, kawaii left, Voldenet left, ugexe left, nine left, nebuchadnezzar left, |Tux| left, elcaro left, rba left, samebchase left, MasterDuke left, djinni` left, codesections left, japhb left, ab5tract left, sjn left, quotable6 left, nativecallable6 left, committable6 left, unicodable6 left, discord-raku-bot left, zostay left, patrickb left, summerisle left, camelia left, maettu left, leont left, SmokeMachine left, Geth left 04:23 RakuIRCLogger__ joined, [Coke] joined, vrurg joined, lizmat joined, lucs joined, shmup joined, RakuIRCLogger joined, RakuIRCLogger left 04:24 [Coke] joined, vrurg joined, lizmat joined, lucs joined, shmup joined, RakuIRCLogger joined, RakuIRCLogger left 04:34 evalable6 left, reportable6 left, jdv left, sourceable6 left, bisectable6 left, releasable6 left, bloatable6 left, statisfiable6 left, shareable6 left, benchable6 left, tellable6 left, gfldex left, samcv left, bartolin_ left, jjatria left 04:36 evalable6 joined, reportable6 joined, jdv joined, sourceable6 joined, bisectable6 joined, releasable6 joined, bloatable6 joined, statisfiable6 joined, shareable6 joined, benchable6 joined, tellable6 joined, gfldex joined, samcv joined, bartolin_ joined, jjatria joined 05:05 normietotechie[m joined 06:00 reportable6 left 06:02 reportable6 joined 07:02 codesections left 07:03 codesections joined
nine lizmat: Int(Str) does not even work on commit 5a869366e 08:32
08:34 squashable6 left 08:38 squashable6 joined
nine Commit f3c050ef0c3e684727a8218cd2552c0bf047a459 fixes the regression in t/02-rakudo/99-misc.t 09:11
Apparently geth is down?
10:22 RakuIRCLogger__ left 10:23 Geth joined, RakuIRCLogger joined
Geth rakudo/main: f3c050ef0c | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix missing IMPL-EXPR-QAST method on VarDeclaration::Placeholder::Positional
 10:24
nine m: "yes" andthen "{dd $_}"
camelia "yes"
Use of Nil in string context
in block at <tmp> line 1
Geth rakudo/main: 0482ee7f79 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: ensure declarations work in term positions where appropriate

E.g. True andthen my $a;		 10:25
rakudo/main: 0482ee7f79 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: ensure declarations work in term positions where appropriate

E.g. True andthen my $a;
lizmat oops :-) 10:26
the webhook re-delivery interface on Github is ... slow and confusing 10:56
ah, I see where my confusion comes from: I tested the type.rakutest without RAKUDO_RAKUAST (in which case it passes) 10:59
m: dd Int(Str)
camelia Int(Str)
lizmat because that works
in the old grammar
and I was only going by the number of passing tests in make test, and that seemed correct 11:00
11:02 codesections left, codesections1 joined
Geth rakudo/main: c0c08a7f67 | (Elizabeth Mattijsen)++ | t/12-rakuast/types.rakutest
Disable tests for Int(something) for now
 11:02
lizmat 132/143 11:03
11:04 codesections1 is now known as codesections, Geth left, Geth joined
lizmat nine: in token typename, it looks like "accept" is not getting set: 11:19
'(' ~ ')' [<.ws> [<accept=.typename> || $<accept_any>=<?>] <.ws>]
aaah
nine "yes" andthen "{dd $_}" is a horrible case to support :/ "{dd $_}" gets compiled to a block and a call to that block, as you'd expect. The andthen thunks its RHS. For this to work, the block that's contained in the string must appear inside the thunk's block. And that although an expression is not a scope by itself. 11:32
The old Actions uses annotations and statement ids to find such blocks and moves them after the fact
lizmat yuck 11:39
nine: any idea about what's wrong in the grammar? $<accept> just doesn't get set
nine m: True andthen my $a = 1; say $a 11:40
camelia 1
lizmat which causes the Int(Str) issue, as that expects $<accept> to contain Str
nine So expression thunks cannot even be real lexical scopes. Otherwise that wouldn't have worked
lizmat right, but the aren't ?
or they're created as an inner block with $_ passed in automatically ? 11:41
nine That's what we do for thunks: create a QAST::Block with a parameter. And we somehow need to add inner blocks to this, but otherwise ignore it when it comes to lexical scopes. 11:43
lizmat: commit b710020b27c5b3251af92e6f2f276e880800038d changes semantics. Are the new semantics actually correct? 11:45
11:46 linkable6 left, linkable6 joined
lizmat changes semantics in what way? 11:48
nine Before, we removed only the very specific colonpairs :D, :U and :_, now it's all colonpairs.
lizmat do we have other colonpairs ? 11:49
anyways, I already tried reverting that commit, and it didn't fix oit
*it
also: it *does* wind up in Actions.type-for-name 11:50
but $<accept> is just never set
but for Int(), $<accept_any> *is*
I guess my grammar fu is insufficient :-(
nine That's not correct. $<accept> _is_ set 11:51
The <!{ nqp::isconcrete($<accept>.ast) }> check however stumbles over the fact that $<accept>.ast is a RakuAST::Type::Simple object instead of the type object itself. 11:52
lizmat so an nqp::istype($<accept>.ast, $*R.actions.r('Type',"Simple')) would be in order? 11:58
self.actions 11:59
nine No, definitely not.
12:00 reportable6 left
lizmat ok, then I don't see the way forward here 12:00
nine For one, there are other types than just ::Simple. And then, can maybe_typename even match anything but a type?
lizmat I don't know, you tell me :-)
nine Before figuring out a solution, you have to find out, what that check is actually trying to prevent. 12:01
lizmat eliminates the check and starts testing
12:02 reportable6 joined
lizmat removing the test makes Int(Str) work 12:03
now on to testing 12:04
see what broke (or got fixed)
735/1355 12:10
so no change... I'd say I'm going to commit that change
or maybe not: c76d9324a9f67e4075683e mentioned something about runtime sigilless vars 12:14
m: my \a = "42"; dd Int(a)
camelia 42
lizmat now, with RAKUDO_RAKUAST this gives: Symbol 'a' does not have a compile-time value 12:15
so maybe we need to check for the ast to have a compile-time value ? 12:16
nine ^^
nine What RakuAST node type does a compile to?
lizmat RakuAST::Term::Name 12:17
nine So a check for RakuAST::Type would eliminate that 12:18
lizmat so <?{ nqp::istype($<accept>.ast,RakuAST::Type) }>
with RakuAST::Type being looked up and so 12:19
nine yes, like that
lizmat ack
meh, at that time, it *is* actually a RakuAST::Type::Simple 12:27
call IMPL-CAN-INTERPRET on it ? 12:29
or maybe that's the problem? that the "a" wasn't turned into a RakuAST::Term::Name ? 12:33
the "a" in (a) in my \a = "42"; dd Int(a)
$*R.is-name-type seems to think that "a" is a type 12:41
looks like "a" is a RakuAST::Declaration::External::Constant 12:42
which at least seems to have the ::Constant part wrong 12:47
nine: should a RakuAST::Declaration::External::Constant be considered a type ?? 12:50
I think not?
nine nope 12:51
lizmat ok, will look further there :-) 12:52
nah, false trail :-( 13:00
ok, I think I found a solution, spectesting now 13:09
Geth rakudo/main: 4a1fad5898 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: fix handling of constants in coercing situations

In the "maybe typename" check, check if the given name is a known type (by name). However, some ASTs (specificall RakuAST::Type::Coercion) do not have a name: take that to mean it is indeed a type.
The ::Coercion case happens with embedded coercions, such as Int(Str())		 13:28
rakudo/main: 7fae9a116f | (Elizabeth Mattijsen)++ | t/12-rakuast/types.rakutest
RakuAST: activate Type coercion tests again
lizmat sadly, no impact on roast tests 13:29
Geth rakudo/main: 96c68ec569 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST: change .raku of RakuAST::Term::Name

The name part is a RakuAST::Name, which can be quite involved, so give it its own line		 13:37
nine Are all possible node types there that don't have a .name coercion types? 13:38
lizmat Type::Coercion is the only one I've seen there until now 13:40
do you have suggestions for others to check ?
nine In that case, why not check for Type::Coercion directly?
lizmat well, *that* felt fragile :-) 13:41
but if you'd rather have that check in there, I'll do that
nine Which indicates incomplete understanding
lizmat fair enough 13:43
nine To be fair: it's obviously an improvement over the clearly broken state it was in before. So it's clearly a valuable fix. 13:49
Geth rakudo/main: d96a1b9554 | (Stefan Seifert)++ | 2 files
RakuAST: make blocks embedded in thunks nest properly

In "yes" andthen "{dd $_}" the "{dd $_}" gets compiled to a block and a call to that block. The andthen thunks its RHS. For this to work, the block that's contained in the string must appear inside the thunk's block. And that although an expression is not a scope by itself.
Fix by making expressions ImmediateBlockUsers if they are thunked and then adding block declarations to the thunk block.		 13:50
nine I really hope this ^^^ holds. It's so much cleaner than the stunt the old frontend pulls.
lizmat i hope so too 13:59
I was thinking, maybe $*$ needs a "is-type" method that would abstract the istype(Coercion) || name is type logic 14:00
*$R
$*R *sigh*
Geth rakudo/main: bd23fda5e6 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: change is type test to something matching experience
 14:03
14:05 Geth left, Geth joined
Geth rakudo/main: 073da5cd80 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix compilation order of regex thunks

A regex thunk's body must be compiled before itself is compiled as a declaration as the declaration needs the body's code.		 15:23
rakudo/main: 991ebca960 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix names in shapes in variable declarations not getting resolved
 15:58
rakudo/main: a5be6d2a64 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix container type in QAST but not in SC
nine And still the one test file I'm working on doesn't pass yet... but others do :)
lizmat now for something completely different: assume I have an int32 with a value, do we have a (semi-) official way to interpret that as a num32 ? 16:28
bit for bit
742 / 1355 ! 16:33
Geth tap-harness6: tbrowder++ created pull request #62:
Use more App::Mi6 capability to add three test buttons to README		 17:17
17:19 Geth left, Geth joined
lizmat m: say Q|::("Int")|.AST.statements.head.expression.name 17:50
camelia RakuAST::Name.new(
RakuAST::Name::Part::Expression.new(RakuAST::QuotedString.new(
segments => (
RakuAST::StrLiteral.new("Int"),
)
))
)
lizmat nine: ^^ it feels to me that this is missing an RakuAST::Name::Part::Empty as the argument to RakuAST::Name.new
*first
18:00 reportable6 left 18:02 reportable6 joined
nine I guess that depends on whether you see that :: as part of the name or as a purely syntactic hint. The AST seems unambiguous even without that Empty part 18:07
lizmat except for the canonicalization
then, so I'm fixing that now
otherwise ::("Int") would just canonicalize to "Int" 18:08
Nemokosch what problem could that cause? 18:09
lizmat it would eval to a string rather than the Int type object ?
nine: oooh...... "$_ := 42" bombs with Cannot compile bind to RakuAST::Var::Lexical 18:12
looks like it would make t/spec/S02-magicals/dollar-underscore.t pass 18:13
nine Interesting. What's the difference to a my $a; $a := 42;? The $a should also be just a RakuAST::Var::Lexical, shouldn't it?
lizmat the AST is the same, apart from needing to define $a 18:14
and the name of the Var::Lexical obviously
nine So there must be more condition than just it being a Var::Lexical 18:15
lizmat I'll check it further 18:16
I ran into it when not wanting to do another level of indentation with given
Nemokosch hm, but when you EVAL a string, does it not become, like, interpreted as code? 18:17
nine difference between '"Int"' and 'Int'
lizmat what nine said :-) 18:18
nine But even the latter, i.e. Int would still be semantically different from ::("Int")
lizmat as Int would be compile time, and ::("Int") would be runtime ? 18:20
Geth rakudo/main: b685e6769e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix deparse/raku of RakuAST::Name::Part::Expression

Well, actually the canonicalization of RakuAST::Name::Part::Expression		 18:24
rakudo/main: 892d76e4a9 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add tests for RakuAST::Name::Part::Expression

And more general RakuAST::Name tests
nine Yes, though to be fair, both docs and design claim otherwise. 18:25
lizmat he... :-)
Nemokosch hmm 18:26
lizmat m: say Q|my $a; $a|.AST.statements.skip.head.expression.can-be-bound-to 18:28
camelia True
lizmat m: say Q|$_|.AST.statements.head.expression.can-be-bound-to
camelia False
lizmat the reason we cannot bind to $_
nine: apparently self.resolution.can-be-bound-to is False for $_ 18:33
nine That sounds easy to fix? 18:38
lizmat indeed: + method can-be-bound-to() { True } 18:42
meh, it also needs a IMPL-BIND-QAST then :-) 18:43
18:50 NemokoschKiwi joined 18:51 NemokoschKiwi left
Geth rakudo/main: 40e2e095fe | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make sure $_ $! $/ can be bound to
 18:53
lizmat sadly, no ++ on tests
dinner& 18:54
Geth rakudo/main: 47342e10d5 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: support specifying key type on hash declarations

e.g. my %h{Int}		 19:25
nine And that's t/spec/MISC/bug-coverage.t finally passing
19:26 [Tux] left, tbrowder left 19:27 tbrowder__ joined, [Tux] joined
MasterDuke nine: i don't really want to distract you too much from rakuast work, but have you looked at github.com/MoarVM/MoarVM/pull/1746 at all? it looks like i need to do some minor cleanup and/or add a small companion nqp pr, but iirc it does pass a spectest locally 19:36
nine MasterDuke: how about a trade? You fix something in RakuAST and I'll review that branch of yours? 19:39
:D
MasterDuke ha 19:41
tbh, i have been looking at t/spec/S32-num/rat.t and it's `No such method 'add-colonpair' for invocant of type
'RakuAST::ColonPair::Value'` off and on, but haven't had a fix yet
nine Where exactly does it throw that? 19:45
gfldex /lastlog RAKUDOAST 19:50
/lastlog RAKUDO
MasterDuke    at SETTING::src/core.c/Exception.pm6:64  (/home/dan/Source/perl6/rakudo/blib/CORE.c.setting.moarvm:throw) 19:54
 from src/Perl6/Metamodel/Configuration.nqp:60  (/home/dan/Source/perl6/rakudo/blib/Perl6/Metamodel.moarvm:throw_or_die)
 from src/vm/moar/dispatchers.nqp:676  (/home/dan/Source/perl6/rakudo/blib/Perl6/BOOTSTRAP/v6c.moarvm:report-method-not-found)
 from src/vm/moar/dispatchers.nqp:613  (/home/dan/Source/perl6/rakudo/blib/Perl6/BOOTSTRAP/v6c.moarvm:)
 from src/Raku/Actions.nqp:782  (/home/dan/Source/perl6/rakudo/blib/Raku/Actions.moarvm:EXPR)
nine I'm a bit torn on ops like sp_p6oget_u as that will do exactly the same as sp_p6oget_i. That's one argument why we don't need the extra op (and it's JIT code). On the other hand, with the variants like sp_p6oget_u32 there _is_ a difference to the _i versions 19:56
gfldex nine: gist.github.com/gfldex/88777693f48...267bcf33be 20:02
nine m: Q|StrDistance.new(:before<a> :after('b' x 42))|.AST.EVAL
camelia ===SORRY!===
No such method 'add-colonpair' for invocant of type
'RakuAST::ColonPair::Value'
nine Oooh! There's no comma 20:03
m: Q|StrDistance.new(:before<a>, :after('b' x 42))|.AST.EVAL
camelia ===SORRY!=== Error while compiling
Confused
------> stance.new(:before<a>, :after('b' x 42))⏏<EOL>		 20:04
nine How does that work even on the old frontend? 20:05
lizmat 743! 20:17
nine: looks like $_ is leaking out of "if" scopes in some situations 20:21
if 1 { $_ = 666 }; say $_; # 666 20:22
evalable6 666
lizmat m: if 1 { $_ = 666 }; say $_
camelia 666
lizmat that is.... surprising?
looks like an existing bug ? 20:23
ah, no, of course, if is not topicalizing 20:24
m: $_ = 42; if 1 { $_ = 666 }; say $_ 20:27
camelia 666
lizmat m: $_ = 42; if 1 { $_ := 666 }; say $_
camelia 42
lizmat ????
with RAKUDO_RAKUAST it says 666 in both cases 20:28
that actually feels more correct to me than with the old grammar
nine: is it correct that the body of a role is a RakuAST::Sub ? 20:49
with the name of the role ?
and a multi at that ? 20:50
with multiness "1" ?? 20:51
nine Yes, all of that is rather important 21:01
lizmat but a bit of a hack ? 21:03
nine The hackiest bit of it is surely the Actions replacing the Block object created by the parser with a Sub 21:05
lizmat why does it need to be a Sub ?
wouldn't a subclass of Sub like RakuAST::RoleBody be more appropriate ? 21:06
nine It needs to be a Sub because it needs to be a multi
Would that change anything?
lizmat well, it would make more sense then when trying to build a role using RakuAST calls ? 21:07
nine Why? 21:08
lizmat needing to teach people to put a Sub in the body of a Role to make it work ?
nine The alternative seems to be teaching people to put a RoleBody in the body of a Role to make it work. 21:09
lizmat well, at least *that* seems to be more DWIM ?
or RoleBlock 21:10
nine Why would it seem that?
lizmat needing to specify a "multiness" of "1", instead of "proto" or "multi" ? 21:11
nine I have to admit "role" would be a better value there :) 21:12
lizmat nine: could you explain why it would need to be a multi sub? what evil hackery lives there? 21:14
nine I now wonder if multiness actually needs to be set. I can't find any effect multiness(1) would have 21:15
Oh, that's simple: we actually use the multi dispatcher to pick a candidate from a parametric role group. 21:16
lizmat aah... ok, now, that's a bad hack :-)
nine m: role A[Int] { say "int" }; role A[Str] { say "str" }; class C does A[1] { } 21:17
camelia int
lizmat but... wouldn't it make more sense to put that sub into another (hidden) attribute ?
nine No, we don't just pick a role via the dispatcher. We run the full role body. This is a very visible thing 21:18
MasterDuke m: class A { has $.a; has $.b; }; say A.new(:a<c> :b<d>).a     # has that (no comma required) always worked? 21:19
camelia c
MasterDuke committable6: releases class A { has $.a; has $.b; }; say A.new(:a<c> :b<d>).a
committable6 MasterDuke, ¦releases (67 commits): «c␤» 21:20
MasterDuke guess so
nine I really wonder if this is a bug or some horrible feature
lizmat isn't that applies the attributes to A.new, and thus doing the right thing? 21:21
afk&
Nemokosch the interesting thing is that you can just list arguments without the comma 21:29
pretty sure I've heard this from someone at the beginning of my journey
so at least it's probably a known thing
timo1 not having to separate colonpairs with comma has been a feature, but at least at some point didn't work in every context 21:33
i think we had something in actions or so called maybe "hunt loose colonpairs" :D 21:34
nine hunt_loose_adverbs_in_arglist which became migrate_colonpairs 21:38
Why, oh why! 21:40
MasterDuke: so it seems like to fix that test, you'll hopefully find a more elegant way to support this............thing 21:51
timo1 i'm now pulling the trigger on a pc upgrade. getting a ryzen 9 5900X 21:56
22:40 kjp left 22:44 kjp joined
tbrowder__ timo1: i just got a similar new one and it makes raku smoke! 23:38
timo1 magic smoke?
tbrowder__ smoke as in so fast it burns rubber (you’re too young…) 23:39
gto… 23:40
Geth rakudo/main: 7ca3189b84 | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod
RakuAST: remove RakuAST::LexPad

As the role body logic now uses the RakuAST::Nqp classes, thereby eliminating the need for RakuAST::LexPad
rakudo/main: 166e166832 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST: Tweak RakuAST::Nqp.raku

If there are no arguments, keep it on the same line		 23:45
timo1 "so fast it burns rubber" is how i feel every time the light turns green when i'm in my EV 23:48
tbrowder__ is that a battery burning? 23:53
or an electric bike? 23:54
timo1 the power use indicator only jumps into the "power" part of the spectrum for a tiny moment! 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!