🦋 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 00:03 reportable6 joined 05:06 unicodable6 left, reportable6 left, releasable6 left, statisfiable6 left, bisectable6 left, shareable6 left, quotable6 left, sourceable6 left, nativecallable6 left, notable6 left, committable6 left, squashable6 left, benchable6 left, tellable6 left, coverable6 left, bloatable6 left, evalable6 left, linkable6 left, greppable6 left, shareable6 joined, committable6 joined, bloatable6 joined, benchable6 joined, bisectable6 joined, greppable6 joined, tellable6 joined 05:07 nativecallable6 joined, sourceable6 joined, squashable6 joined, reportable6 joined, evalable6 joined, unicodable6 joined 05:08 quotable6 joined, statisfiable6 joined, linkable6 joined, notable6 joined 05:09 coverable6 joined, releasable6 joined 06:00 reportable6 left 06:03 reportable6 joined
lizmat nine: a golfed case: gist.github.com/lizmat/8da12bbe97b...6456503a77 09:52
not quite the same situation as yesterday (I thought) but still something I think should work 09:53
aha... derive_dispatcher only lives in World, so that code is just Wrong(tm) 10:01
nine No, it's a method of Routine: github.com/rakudo/rakudo/blob/main....nqp#L2459 10:03
lizmat aah... that's why a search for "method derive_dispatcher" didn't show that :-) 10:04
anyways, RakuAST::Declaration::External is not a BEGIN time thingy, so .compile-time-value won't work on it, right ? 10:05
nine Right. You could try replacing resolve-lexical with resolve-lexical with resolve-lexical-constant 10:09
lizmat trying 10:11
it doesn't bomb anymore, but the candidate does not appear to have been added 10:13
nine Probably because it has auto generated a new proto? 10:16
lizmat no, it doesn't get into the else branch 10:17
and the dispatcher it got *is* a Sub object
looks it got the right thing... 10:19
and add_dispatchee is getting called 10:25
and after that, the number of dispatchees is 1 10:29
but meanwhile in Raku land, it is still 0 :-(
nine Wait...that's correct! It's deriving a dispatcher after all, isn't it? 10:33
lizmat I guess.. ? 10:34
so that's not the real thing you're saying ?
if it already a dispatcher, maybe it shouldn't derive, is what you're saying ?
*is 10:35
nine Multis are like any other subs lexical. So adding a multi to the dispatcher should only be a lexical effect as well. That's the point of derive_dispatcher
The behaviour you see is absolutely correct. The more interesting test would be if candidates added outside your EVAL are visible inside that EVAL
(in addition to the candidate added in the EVAL)
lizmat hmmm 10:36
ok, but I guess that would be a severe limitation in the creation of macros 10:38
or, I guess you should be doing your own .add_dispatchee then
nine Why would that be a problem for macros? 10:40
lizmat not technically, but a bit of a WAT 10:41
nine not even that
lizmat gist.github.com/lizmat/7543275e6f5...2b1b9bee6f 10:43
the add_dispatchee would need to live *outside* of the EVEL
*EVAL
nine Why would a macro even use EVAL in any way? 10:44
lizmat to build code to be inserted somewhere ?
ah, you're saying it would just insert the AST 10:45
nine That would be completely missing the point of macros. They are part of compilation itself
lizmat gotcha 10:46
Geth rakudo/main: b5d1ddee0b | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
RakuAST: fix lookup of proto, nine++ for pointers
 10:51
rakudo/main: 62122e575f | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add raku/deparse support for RakuAST::OnlyStar

And also tweak some related raku / deparse thingies		 10:52
rakudo/main: 08930e8aff | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix block thunks not getting an argument in $_

Eg. 42 andthen $_		 11:02
lizmat nine: I borked 2 t/12rakuast test, please ignore those for now, fix on its way 11:05
Geth rakudo/main: fa79f83495 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Deparse.pm6
RakuAST: Unbreak RakuAST::Method deparsing

And reorganize RakuAST::Sub deparsing a bit		 11:08
rakudo/main: 965520bf2e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add tests for RakuAST::OnlyStar
lizmat 728/1355 ! 11:27
m: sub a(Int() $a) { dd $a }; a "42" # nine: this doesn't coerce in RakuAST grammar 11:58
camelia 42
lizmat resulting in "42"␤ output
12:00 reportable6 left
lizmat nine: ah, that looks easily fixable 12:00
12:01 reportable6 joined 12:04 squashable6 left
Geth rakudo/main: 2d54be72ad | (Elizabeth Mattijsen)++ | src/Raku/Actions.nqp
RakuAST: need to look up RakuAST::Name type
 12:06
12:07 squashable6 joined
nine lizmat: line 1321 looks fishy, too, doesn't it? 12:09
And 468 in Grammar
lizmat yep, same thing, will look for more cases like that
those were the ones, looks like it 12:12
Geth rakudo/main: d78754cb23 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: fix some more RakuAST:: class lookups
 12:19
lizmat sadly, doesn't produce any additional passes :-(
13:20 nativecallable6 left, quotable6 left, unicodable6 left, shareable6 left, coverable6 left, committable6 left, tellable6 left, bloatable6 left, reportable6 left, greppable6 left, benchable6 left, bisectable6 left, statisfiable6 left, evalable6 left, notable6 left, linkable6 left, sourceable6 left, squashable6 left, releasable6 left 13:21 tellable6 joined, linkable6 joined, evalable6 joined, coverable6 joined, benchable6 joined, greppable6 joined, shareable6 joined 13:22 statisfiable6 joined, reportable6 joined, unicodable6 joined, notable6 joined, bloatable6 joined, releasable6 joined, bisectable6 joined 13:23 committable6 joined, nativecallable6 joined, sourceable6 joined, squashable6 joined, quotable6 joined
nine It's never the fixes you think 13:30
Geth rakudo/main: 2680101652 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: make constraint on RakuAST::Type::Coercion optional

This simplifies both the Action, as well as any future use in macros		 13:33
rakudo/main: f06c9c3586 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: tweak RakuAST::Type::Coercion|Definedness raku/deparse
 13:43
rakudo/main: 0d9a775669 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add tests for RakuAST::Type::Coercion|Definedness
14:21 timo1 joined
Geth rakudo/main: 8a3289cef7 | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: Tweak no args behaviour of RakuAST::Type::Parameterized

  - make the "args" argument optional, create empty ArgList as default
  - return the base-type of no arguments were specified
This makes Rational ~~ Rational[] return True, as it did with the old grammar		 14:26
rakudo/main: f07fae0d32 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add tests for RakuAST::Type::Parameterized

Also tweak deparsing accordingly		 14:27
15:13 codesections left 16:30 codesections joined
Geth rakudo/main: ce6e903148 | (Elizabeth Mattijsen)++ | t/12-rakuast/terms.rakutest
RakuAST: add one missing .raku roundtrip test
 17:32
17:54 [Coke] joined
timo1 MasterDuke: i have a starting patch for you that you can fiddle into a presentable state, with regards to the for-range-optimization and uints, in the rakudo optimizer 17:55
[Coke] last rakudoc release was by cpan:SOFTMOTH - any issues with me releasing it as fez:coke?
lizmat zef:coke you mean? 17:56
assuming SOFTMOTH is unresponsive, ok?
timo1 fəz
ſez
[Coke] lizmat: just commented here: github.com/Raku/rakudoc/issues/24#...1464965610 17:58
but the version out there doesn't install at all. will give it a day or so
Geth rakudo/optimize-for-range-with-uint-callable: 5031953499 | (Timo Paulssen)++ | src/Perl6/Optimizer.nqp
first attempt to make for-range-loops use uint if the block takes it

  MasterDuke++ found that performance with a single uint arg for the
for loop body was much worse than with int, so here's a case for the optimizer to figure that out and use a uint for counting as well.		 17:59
timo1 all i have done is check the output of --target=optimize, i have not timed this yet
18:00 reportable6 left
timo1 oops, and of course it already asplodes, we don't have an add_u seems like. just as well, add_u and add_i wouldn't do anything different anyway i don't think 18:00
18:01 reportable6 joined
lizmat yeah, add_i would be the same 18:02
*do
which I think was nine's point not implementing them
now I wonder how many WATs we can prevent in the future if they would be defined as aliases somehow 18:03
Geth rakudo/optimize-for-range-with-uint-callable: bf7c1d0db1 | (Timo Paulssen)++ | src/Perl6/Optimizer.nqp
first attempt to make for-range-loops use uint if the block takes it

  MasterDuke++ found that performance with a single uint arg for the
for loop body was much worse than with int, so here's a case for the optimizer to figure that out and use a uint for counting as well.		 18:07
timo1 force-pushed :) :)
i think we could very well cause WAT by making them available but not having any difference in behavioru 18:08
"why is add_i and add_u the same???" is a WAT i find more bothersome than "why is there no add_u???"
anyway with that commit ~/raku/install/bin/raku -e 'my int $a = 0; for ^10_000_000 -> int $x { $a += $x }; say $a' takes the same amount of time as ~/raku/install/bin/raku -e 'my uint $a = 0; for ^10_000_000 -> uint $x { $a += $x }; say $a' 18:09
lizmat timo1++
timo1 *about* the same :D
lizmat within noise I hope 18:12
[Coke]: re rakudoc, perhaps move it to raku-community-modules and release from there as zef:raku-community-modules ? 18:15
timo1 i have also not tried spec tests either 18:16
i have also also not tried a reverse for range loop, nor one with a step
adding MD's "more uint" patch for moarvm can at least improve the "reprop decont_u unsupported in P6Opaque Int" but i think that happens outside the loop, and therefore 1) will not be executed from the specialized code, as we will already have entered the loop and most probably performed OSR and 2) would only have happened once anyway, which should give negligible costs in this case for that 18:20
reason
[Coke] lizmat: it's already in raku/ 18:21
That seems "more official" to me, no?
lizmat ah, duh... then by all means, I'd say release!
Geth rakudo/main: cf2f709a84 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: add deparsing/raku/test for RakuAST::Type::Setting

The tests are actually TODOd as the RakuAST::Type::Setting class only does lexical lookups at the moment, rather than just looking in the setting.
Also of note: there is currently **NO** syntax for lookups in the ... (15 more lines)		 18:26
rakudo/main: b710020b27 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add RakuAST::Name.without-colonpairs

And use it. For readability as well as performance.		 18:48
rakudo/main: 13005cdd34 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: implement 't' type expression thunking
 19:00
rakudo/main: 8cb0dcb37c | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: Only thunk infixes that actually need thunking

with/without probably need special handling as will meta ops
rakudo/main: 301ca0dcd4 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: fix thunking of chained infix operands

Need to repeat the last thunk mode for all remaining operands when chaining.
nine lizmat: the impact of these ^^^ for example is a welcome surprise :) And I haven't even fixed the test file I'm after yet
19:04 ab5tract joined
[Coke] auth on raku/rakudoc says github:raku on the class and meta6 - but the dist was uploaded to cpan 19:47
what's the right config setup here? 19:48
lizmat well, it should be a "zef:xxx" auth matching the class and the META 19:53
and it should be a zef:xxx that allows uploading zef:xxx 19:54
so most likely zef:coke?
[Coke] ok. and I think mi6 was the tool it looks like was used before. 19:56
lizmat hmmm...I just realized that where the repo lives, doesn't really matter for the auth 19:58
so maybe zef:raku-community-modules *would* be the best?
[Coke]: assuming you can upload to zef and are member of raku-community-modules ?
735 / 1355! 20:06
[Coke] i just uploaded it as me for now.
it was on cpan before, so this is an upgrade. 20:07
mi6 is nifty
lizmat yup, agree
nine: unfortunately, it seems to have borked one of the type tests, Int(Str) specifically 20:08
[Coke] Will porbably adopt it for my personal stuff!
lizmat nine: but only with RAKUDO_RAKUAST=1 20:12
"Cannot create an Int from a 'Str' type object"
nine: what changed is that Int(Str) is no longer a type per se 20:15
m: use Test; is-deeply Int, Int(Str)
camelia not ok 1 -
# Failed test at <tmp> line 1
# expected: Int(Str)
# got: Int
lizmat ^^ nine: with RAKUDO_RAKUAST=1 this will bomb on the Int(Str) 20:16
m: Int(Str) 20:18
camelia WARNINGS for <tmp>:
Useless use of constant integer Int(Str) in sink context (line 1)
lizmat ^^ golfed
looks like the wrong QAST is generated
it gets QASTed to nqp::call(Int,Str) 20:19
m: use nqp; nqp::call(Int,Str) 20:20
camelia Cannot create an Int from a 'Str' type object
in block <unit> at <tmp> line 1
lizmat whereas it should just be a WVAL(Int(Str)) 20:21
lizmat goes afk& 20:32
20:41 djinni` left, jdv left, eof left, patrickb left 20:42 djinni` joined 20:44 summerisle joined 20:45 patrickb joined 20:46 jdv joined
MasterDuke timo1: nice! does it actually end up generating the same ast as the int version then? or is still the "non range-optimized" ast, but just faster? i'll test later (hopefully this evening) and see how it interacts with my moarvm branch and my rakudo patch 21:12
timo1 it does make the same ast 21:59
plus/minus the lt/gt_u instead of _i

Powered by Cro and the Raku® Programming Language.

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

Thank you!