00:43 kjp left 00:44 kjp joined 00:47 kjp left, kjp joined 00:48 [Coke]_ left 02:33 sena_kun joined 04:20 ilogger2 left, ilogger2_ joined 07:00 andinus left 07:02 andinus joined
ab5tract So weird 07:06
m: with 42 { .say; say $_ ~~ Mu:U}
camelia 42
True
ab5tract would this be considered a "topicalized smartmatch"? 07:27
also, in theory this shouldn't happen if `RAKUDO_OPTIMIZE_NOSM` is set, right? because it seems to still occur for me even when that is the case 07:38
07:38 sena_kun left
lizmat m: say $_ ~~ Mu:U 09:25
camelia True
lizmat m: $_ = 42; say $_ ~~ Mu:U 09:26
camelia True
lizmat m: $_ = 42; say $_ ~~ Mu
camelia True
lizmat m: $_ = 42; say $_ ~~ Mu:D
camelia True
lizmat m: say $_ ~~ Mu:D
camelia False
lizmat m: say 42 ~~ Mu:U
camelia False
lizmat m: say ($_ = 42) ~~ Mu:U 09:27
camelia False
lizmat m: $_ = 42; say $_ ~~ Mu:U
camelia True
lizmat weird
timo you can set RAKUDO_OPTIMIZER_DEBUG to see what it thinks. i'm not sure why it thinks what it thinks though 10:37
is "topicalized smartmatch" about when the usage of ~~ causes $_ inside "it" to refer to the LHS? like how "foo" ~~ /o/ would have "foo" be in the $_ for that moment? 10:38
lizmat m: $_ = 42; say $_<> ~~ Mu:U
camelia True
timo does camelia let us set env vars that are active before compilation starts, or is that an evalable feature only? 10:39
i guess BEGIN might actually do it
m: BEGIN { %*ENV<RAKUDO_OPTIMIZER_DEBUG> = 1 }; say $_ ~~ Mu:U 10:40
camelia True
timo m: RAKUDO_OPTIMIZER_DEBUG=1 say $_ ~~ Mu:U
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> RAKUDO_OPTIMIZER_DEBUG=1⏏ say $_ ~~ Mu:U
expecting any of:
infix
infix stopper
statement end
statement mo…
timo evalable6: 2024.08 RAKUDO_OPTIMIZER_DEBUG=1 say $_ ~~ Mu:U 10:41
evalable6 (exit code 1) 4===SORRY!4=== Er…
timo, Full output: gist.github.com/1062f66ce3d15e583e...06bd17aa3c
timo evalable6: RAKUDO_OPTIMIZER_DEBUG=1 say $_ ~~ Mu:U
evalable6 (exit code 1) 4===SORRY!4=== Er…
timo, Full output: gist.github.com/9d53084e87b7856044...fa959de1ec
timo i could have sworn ... 10:46
also, i think there's new unicode versions that we don't have in moarvm yet 11:24
is there a proposal yet somewhere for letting user code opt in to an older unicode version? 11:25
ab5tract Do they remove characters/codepoints? 11:53
timo "they", you mean the versions we don't have in moar yet, or when downgrading your unicode version? 12:35
lizmat with downgrading: yes, very much so 12:37
12:47 sena_kun joined 12:54 [Coke]_ joined
[Coke] I'm not even sure we can interrogate which version of unicode we're running yet 12:55
m: say Unicode.version
camelia v15.0
[Coke] ok, we can do that. \o/
lizmat fwiw, that check is fed by checking the existence of "new" codepoints 12:58
ab5tract Sorry, I meant do new versions remove or alter codepoints? 13:12
I guess I’m curious about the use case for using an old revision
lizmat what I know of it, is that ew codepoints get added, new rules get added, and maybe a rule will be expanded 13:14
afaik the Unicode consortium attempts to be backward compatible
ab5tract does nqp::istype take smileys into account? 13:52
lizmat it should 13:53
m: use nqp; dd nqp::istype(42,Int:D) 13:54
camelia 1
lizmat m: use nqp; dd nqp::istype(Int,Int:D)
camelia 0
ab5tract Duh, not sure why I didn’t check myself 13:55
This smartmatch optimization bug is weird 13:56
lizmat remember that internally, nqp::istype is basically nothing more than an int lookup in a list of ints 13:59
all of the magic exists in the creation of the lists of ints 14:03
ab5tract Makes sense 14:06
It looks like this optimization only oltimizes the type match case for $_ “by accident” 14:07
At the time of the optimizer, $_ always has value Mu, returns Mu (Mu:U, to be precise) 14:08
Ah! A helpful golf 14:21
m: say Mu:D ~~ Mu:U 14:22
camelia True
timo it occurs to me maybe we should have some kind of helpful macro in nqp that is essentially "if, but evaluated only the first time" using dispatchers, so debug output code can be cheaper and therefore used in more places
ab5tract Oo, that would be really nice 14:23
timo shouldn't even be difficult. just gotta make sure it actually disappears the debug code fully when spesh hits it
lizmat m: use nqp; dd nqp::istype(Mu:U,Mu:D)
camelia 0
lizmat m: use nqp; dd nqp::istype(Mu:D,Mu:U) 14:24
camelia 1
timo if you have such an "if" with a block, we'll definitely still capturelex for it though when entering its outer
unless the static optimizer is able to inline the block directly
ab5tract lizmat: but shouldn’t the intended semantics of ~~ differ from istype here? 14:25
I wouldn’t expect the not-definite forms to accept the definite ones
But probably I haven’t thought through the implications to the type system 14:26
lizmat :U and :D are both specializations 14:27
ab5tract Yeah, it makes sense actually
Geth nqp/main: 4eb6813287 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest fixes
 15:15
rakudo/main: 1a7b8460b1 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for latest NQP/MoarVM fixes
 15:24
ab5tract m: use nqp; say nqp::eqaddr(Mu:U, Mu)
camelia 0
ab5tract Any thoughts on how to make this check? Maybe the answer is to get the non-smiley version of Mu via the HOW object? 15:26
the check I’m actually trying to do is nqp::eqaddr($rhs-type, Mu:U), of course 15:27
lizmat eqaddr? not istype ? 15:33
ab5tract istype is true for all types checked against Mu, no?
lizmat yes, unless the type comes from NQP I think? 15:34
but eqaddr would only be 1 for Mu:U,Mu:U ? 15:35
ab5tract That’s the only time I want the check to pass :)
lizmat qp::eqaddr($rhs-type.WHAT, Mu:U) ?? 15:36
*n
15:36 Voldenet_ joined
ab5tract Sorry if I wasn’t clear 15:36
The question is how to get the type object Mu:U inside of the optimizer
gethllsym didn’t work, for example 15:37
Ah, of course. I would need to add a corresponding bindhllsym 15:40
lizmat yup
ideally only done once in a process :-) 15:41
it *is* a hash lookup
15:41 [Tux] left, Voldenet left, |Tux| left, timo left, Voldenet_ is now known as Voldenet 15:43 [Tux] joined, timo joined 15:47 |Tux| joined
ab5tract I’ll do my best not to de-optimize the optimizer ;) 15:48
15:52 nine_ left, nine joined
timo we should maybe build a test suite that tests the output of the optimizer, though of course it can be a bit unstable over time 16:54
and it would take a lot of effort probably
ab5tract probably a worthy effort once we start to attach the optimizer to RakuAST outpu 16:59
*output
I wonder how much `want` (or rather, lackthereof) in RakuAST is going to prove an issue 17:00
I guess it should be fine as long as the optimizer is interested in genuine want nodes, rather than annotations 17:01
I think I've got a resolution for the smartmatch edge case nailed down 18:14
Geth rakudo/fix-mu-u-in-optimizer: de895321ef | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)		 18:26
linkable6 R#5644 [open]: github.com/rakudo/rakudo/issues/5644 [Fixed in RakuAST] rakudo optimizer changes behaviour of `$_ ~~ Mu:U`
ab5tract In that code I do a `nqp::eqaddr($sm_type, $!symbols.Mu-U)` -- do you think that's worth micro-optimizing to be `nqp::eqaddr($sm_type, nqp::ifnull($mu-u, $!symbols.Mu-U)`? (where `my $mu-u := nqp::null;` is defined above the method in the class-package scope) 18:33
Geth rakudo/fix-mu-u-in-optimizer: 18d9a04db6 | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)		 18:50
linkable6 R#5644 [open]: github.com/rakudo/rakudo/issues/5644 [Fixed in RakuAST] rakudo optimizer changes behaviour of `$_ ~~ Mu:U`
ab5tract too late, it's micro-optimized now :)
Geth rakudo: ab5tract++ created pull request #5645:
Address a small but significant corner case in the optimizer		 19:59
rakudo/fix-mu-u-in-optimizer: 830731f606 | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)		 20:02
linkable6 R#5644 [open]: github.com/rakudo/rakudo/issues/5644 [Fixed in RakuAST] rakudo optimizer changes behaviour of `$_ ~~ Mu:U`
rakudo/fix-mu-u-in-optimizer: 57b3c28191 | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)
ab5tract timo: I too have sometimes wondered if we could find some ways to suppress channel notifications from PRs. maybe we ought to raise it to a problem-solving ticket? 20:05
timo is it problem-solving material? i'd have just opened a ticket in geth's repo 20:22
Geth: source
Geth timo, Source at github.com/Raku/geth To add repo, add an 'application/json' webhook on GitHub pointing it to webhooks.liz.nl/?chan=%23raku and choose 'Send me everything' for events to send | use `ver URL to commit` to fetch version bump changes
timo the URL for webhooks in the readme of that repo is probably out of date 20:23
i was hoping that maybe the -o aka --push-option feature in "git push" might allow putting arbitrary extra data into what the "push" event webhook on github gives you 20:29
ab5tract a Geth ticket is probably more appropriate indeed. I was just reaching for a way to not lose track of it 20:51
timo we could have something totally simple like, if your branch name ends in "-nogeth" it won't get output to irc 20:55
Geth rakudo/fix-mu-u-in-optimizer: e15076bad9 | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)		 21:02
linkable6 R#5644 [open]: github.com/rakudo/rakudo/issues/5644 [Fixed in RakuAST] rakudo optimizer changes behaviour of `$_ ~~ Mu:U`
ab5tract I'd be happy if it would ignore force-pushes, as that's a pretty clear scenario of "oops, I needed to fix something" 21:03
timo is there any archetype we can check against to identify a refinement type or similar variants of Mu that don't behave like Mu? 21:04
ab5tract I wish I knew of one. I'd be using it, if so 21:05
timo OK
ab5tract even then, I think you'd need to do something like: determine that `Mu` is the un-refined type (for checking with nqp::eqaddr, as nqp::type($foo, Mu) will always be true) 21:06
ah, that looks easy enough via `base_type` 21:09
Geth rakudo/fix-mu-u-in-optimizer: d5c73e2d36 | ab5tract++ | 2 files
Address a small but significant corner case in the optimizer

  (Fixes R#5644 [#5644])
  > with 42 { say $_ ~~ Mu:U }
  \# True
  > my $m = Mu:U; say $m ~~ Mu:U }
... (17 more lines)		 21:12
linkable6 R#5644 [open]: github.com/rakudo/rakudo/issues/5644 [Fixed in RakuAST] rakudo optimizer changes behaviour of `$_ ~~ Mu:U`
ab5tract I guess the question is whether using an bindhllsym/gethllsym + nqp::eqaddr($_, Mu:U) is more costly than calling nqp::can($type.HOW, "base_type) and then calling it 21:15
*missing quote end 21:16
timo do we have a cheap dispatcher for call-if-exists? 21:27
ab5tract you mean a sort of all-in-one if-can-then-call? 21:28
timo yeah 21:29
ab5tract not that I know of. but now that you mention it, does nqp dispatch through the dispatchers defined in vm/moar/dispatchers.nqp? 21:31
timo i would assume nqp uses a bunch of dispatchers for stuff already 21:32
they also do some variable lookups too, right?
ab5tract aside from that question, I recently used a `if (my $method := nqp::can(...)) && $method($object, ...)` pattern recently that nine reviewed. I expect if there were a better option, he would have mentioned it
counterpoint: the above example was *within* dispatchers.nqp, so it might be that it was simply the best available 21:33
I only see `raku-` prefixes on the dispatchers registered in dispatchers.nqp 21:36
obviosly there are `nqp-` ones registered in nqp/core/dispatchers.nqp, but I don't think those were part of `newdisp`? 21:38
timo i should take a look, though maybe the most reliable way is to take a spesh log from a pure-nqp process and see where dispatch_ crops up hehe.
ab5tract ah, no, I'm once again typing my findings too fast 21:39
`#?if moar` sits at the top of that file
timo nqp-stringify, -intify, -uintify, and -numify exist as dispatchers inside of nqp 21:40
ab5tract I also see `nqp-find-meth`, `nqp-meth-call`, and more 21:41
it doesn't seem that there is a `nqp-meth-call-if-found` 21:42
so is `nqp::dispatch('nqp-istype', $object, $type)` faster than `nqp::istype($object, $type)`? 21:43
timo huh, i'm not sure 21:45
ok, here's the answer 21:48
nqp::istype inside of moarvm goes through the 6model type-check cache, then if that didn't work it calls into whatever dispatcher is called istype_dispatcher in the hll
so if you dispatch to the istype dispatcher instead of using nqp::istype you would be avoiding the cache 21:49
ab5tract Huh.. but newdisp would perform its own form of caching, right? Based on guarded values 21:50
Such that the same value at the same call site doesn’t result in a full dispatch (I might be misremembering..) 21:51
timo well, i know barely a thing about the type check cache 21:52
ab5tract Still, it seems that there might be room for that dispatcher you described 22:02
22:03 sena_kun left
timo maybe it's already fast to do can + invoke 22:04
ab5tract In the meantime, I guess one can cache the outcome of the nqp::can call and apply it to any object that matches a given type
Though maintaining duck typing would require a bit of juggling 22:05
timo can already goes via a dispatch to lang-find-meth, actually findmethod, tryfindmethod, and can are generated with the same little sub that has a few differences based on the name of the op being compiled 22:07
ab5tract Nice 22:11
I wonder if there is any performance advantage for the optimizer of moving all the symbol caching out of method calls (eg, $!symbols.Mu, etc) and into package lexicals + nqp::ifnull assignments 22:26
timo i wonder how much it would be worth to make all the lookups of core up generators in QASTOperationsMAST more static by using a bit more dispatcher magic 22:27
i don't think that part of compilation takes a lot of time though, so it might be scratching a tiny bit at a >1% thing, dunno 22:28
ab5tract Yeah, it’s often tricky with optimization. Sometimes you know quite clearly both the effort and a tge reward. But all too often it seems like one, the other, or both aren’t very clear in advance and the only way to know if it’s worth it is to go ahead and spend the (maybe unknown or mis-estimated) effort to find out 22:33
timo right
ab5tract Anyway, I’ve clearly entered the philosophical portion of the evening :)
Signing off before it’s too late. Have a good one timo! 22:34
timo night! 22:38

Powered by Cro and the Raku® Programming Language.

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

Thank you!