🦋 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:02 reportable6 joined 00:25 ab5tract left 01:08 melezhik joined 01:10 melezhik left 01:12 melezhik joined 01:16 melezhik left 02:50 melezhik joined 03:01 melezhik left 04:52 linkable6 left, evalable6 left 04:53 linkable6 joined 04:55 evalable6 joined 05:54 kjp left 05:56 kjp joined 06:00 reportable6 left 06:01 reportable6 joined 08:58 sena_kun joined 09:03 frost joined 09:08 kawaii left 09:10 kawaii joined 09:11 ab5tract joined 09:14 frost left 09:18 frost joined 09:19 frost left
ab5tract what does this QAST mean: "QAST::Stmts <b a>"? where is this '<b a>' annotation coming from and (how) do I reproduce it? It's part of a block 09:28
nine That's just an annotation that the RakuAST frontend doesn't yet add. It doesn't make any functional difference and is purely a debugging aid. 09:58
lizmat jjatria ping github.com/rakudo/rakudo/issues/5201 I've yet to find a golf to find the issue with Pop and Game::Entities 09:59
would appreciate an extra eye there :-) 10:00
Nemokosch same 👁️ 10:02
jjatria Oh, interesting. I had not clocked this 10:03
tellable6 2023-02-07T21:26:41Z #raku <melezhik> jjatria I created a simple CI pipeline that also runs a code snippet from http tiny readme, let me know if you are interested and I can create a pr
lizmat jjatria: also, I'm not 100% sure the bisect to github.com/rakudo/rakudo/commit/72...46c378d01e is correct 10:04
jjatria The issue seems related, since the Pop failure is failing on the Pop version of Game::Entities, before it spun into its own distro
lizmat otoh, it does do a lot Int() coercions, so it may indeed be related
jjatria I haven't taken a look at this in a while, but I should be able to dive back in today 10:05
lizmat cool... I'll concentrate on other stuff again then, since I wasn't getting any further with it for an hour or so already 10:06
bisectable6: old=2022.12 (1|2|3).Int 10:07
bisectable6 lizmat, Bisecting by exit code (old=2022.12 new=615b9bf). Old exit code: 0
lizmat, (2023-01-09) github.com/rakudo/rakudo/commit/72...46c378d01e 10:08
lizmat, bisect log: gist.github.com/f3d1cf4d266cb5e5ca...08da2711a5
lizmat bisectable6: old=2022.12 dd (1|2|3).Int 10:09
bisectable6 lizmat, Bisecting by exit code (old=2022.12 new=615b9bf). Old exit code: 0
Nemokosch how is bisectable kept up to date, by the way?
bisectable6 lizmat, bisect log: gist.github.com/572e7aec341b7a20a1...9b1e455cab 10:10
lizmat, (2023-01-09) github.com/rakudo/rakudo/commit/72...46c378d01e
lizmat well, that's one behaviour that changed 10:12
Nemokosch > Cannot resolve caller Int(Int:D: ); 10:13
the error message is wrong, too
m: say 12.Int
Raku eval 12 10:14
lizmat m: dd (1|2|3).Str # yet this works
camelia any("1", "2", "3")
Nemokosch can resolve caller Int(Int:D: ) clearly...
is Str also proto'd on Mu?
oh yes, it is
lizmat that's because Junction has a .Str candidate 10:16
lizmat adds an Junction:D.Int candidate to see if that fixes the issue 10:17
nope, it doesn't 10:20
Nemokosch That's weird...
A junction doesn't have an 'Int' candidate "normally" 10:21
lizmat it used to work because there was nu Mu.Int candidate before
Nemokosch I wonder how that lookup even works
I mean, how a Junction turns into Any's
10:22 linkable6 left, evalable6 left 10:24 linkable6 joined, evalable6 joined
github.com/rakudo/rakudo/blob/615b...n.pm6#L664 is that the main thing? 10:25
lizmat basically yes 10:27
10:31 ab5tract left
Nemokosch hm, find_method can actually find the method to call, unlike can 10:36
10:48 ab5tract joined
Geth rakudo/main: 1841d6d9c2 | (Elizabeth Mattijsen)++ | src/core.c/Junction.pm6
Make Junction:D.(Int|Numeric|Real) work

  - 72856df broke Junction:D.Int
  - Junction:D.(Numeric|Real) were already broken, now fixed
  - let Junction:D.(Str|put) use the same logic
  - reformat some internal comments		 10:50
Nemokosch nice 🎉 10:54
when a Junction is unwrapped, do the elements always become Any? 10:56
lizmat Junctions can't be unwrapped in core, you can only collapse them 10:57
Nemokosch Basically I want to know what actually went wrong 10:58
lizmat well, in the case of .Int, I added a Mu candidate without taking care of the Junction:D case
Nemokosch why did Int work previously and not afterwards? what could it find?
it's easier to understand why it didn't work afterwards 10:59
lizmat because there was *no* Mu candidate before, the normal auto-threading would kick in
Nemokosch why did the normal auto-threading work for Int but not for Real or Numeric?
or did they all have candidates? 11:00
lizmat because Real and Numeric already had a Mu candidate
Nemokosch oh okay 🤦
lizmat m: class A { }; dd A.Numeric
camelia Use of uninitialized value of type A in numeric context
in block <unit> at <tmp> line 1
0
lizmat to allow that to work 11:01
m: dd Mu.Numeric # and this
camelia Use of uninitialized value of type Mu in numeric context
in block <unit> at <tmp> line 1
0
lizmat especially the Mu case :-)
Nemokosch and how does the auto-threading work? When a value is pulled from the underlying data structure of the junction, how does it get its type for the dispatch? 11:02
lizmat something like a|b|c creates a junction 11:03
Nemokosch how did the individual values of ('1'|'2'|'3') find the .Int they needed to call?
lizmat then, when you call an unknown method on it, instead of throwing a dispatch error, it will call the method on all of the Junction's eigenstates *If* the object in question is a Junction 11:04
before my patch that introduced a Mu.Int, the ('1'|'2'|'3').Int dispatch would initially fail, and then the auto-threading would kick in 11:05
with the Mu.Int candidate there, the dispatch would succeed, and auto-threading would not happen
Nemokosch yes, this part I understand 11:06
what I'm curious about how the auto-threading itself could find the right candidates
lizmat that's just normal dispatch on each of the candidates 11:07
m: dd (1|2|3).Foobar
camelia No such method 'Foobar' for invocant of type 'Int'
in block <unit> at <tmp> line 1
lizmat it would fail on any dispatch of the eigenstates of the Junction
Nemokosch does a Junction contain proper Raku objects under the hood?
lizmat yep, it really is just an nqp::list with the eigenstates 11:08
Nemokosch gotcha, thank you
lizmat and there's an eigenstates module if you want to cheat :-)
11:09 ab5tract left
Nemokosch I basically forgot that individual object instances can have a lot of metadata without any containers involved 11:09
more than enough to nail a dispatch 11:10
It would be really cool to have lazy junctions but I have a feeling that it would really kick the complexity off 11:11
lizmat yeah, I've looked into that in the past 11:13
be assured that collapsing Junctions *do* shortcut
so in the case of an .Bool, the first eigenstate to return a trueish value, will shortcut 11:14
Nemokosch yes, that's nice
lizmat in the case of an all junction, the first to return falsish will shortcut, etc
maybe in the future large junctions could race their eigenstates 11:15
Nemokosch the real problem with eagerness is, well, the same as always - you have to pay a big penalty before it even turns out how and why you need the values
lizmat for now, that overhead is simply too much
well the problem is that Junctions are objects on their own 11:16
so something like if $a|$b|$c {
turns into
if ($a|$b|$c).Bool {
aka, first create a Junction, then call .Bool on it 11:17
Nemokosch yep
lizmat with RakuAST it should become easier to change that into $a.Bool || $b.Bool || $c.Bool
because the RakuAST::If class could have separate handling for a RakuAST::Junction object :-) 11:20
and build a different RakuAST:: AST tree 11:21
Nemokosch high-level optimizations should surely become easier 11:22
I'm also hoping that it can make certain things less "surprisingly consistent" 11:24
like the infamous smartmatch to m, s, tr quotes 11:25
to be able to declare that this is not a regular, "localize the topic, call ACCEPTS" smartmatch
not penalize ACCEPTS with having to support this, rather do it on an AST level 11:26
that was a case where consistency manifested as the specific trumping the generic 11:29
if one is able to declare that these smartmatches to quoting constructs are "magic", the generic meaning can stay saner (Matches are now hardcoded in everything smartmatch-related, in order to support that "magic") 11:31
* to support that "magic", as normal, first-class behavior, that has further consequences
12:00 reportable6 left 12:02 reportable6 joined 12:20 ab5tract joined 12:25 frost joined 12:26 frost left, frost joined 12:33 ab5tract left 12:35 frost left 12:43 frost joined 12:46 frost left 12:53 frost joined 13:03 ab5tract joined 13:19 ab5tract left 13:29 ab5tract joined 13:35 ab5tract left 13:36 ab5tract joined 14:04 frost left 14:07 ab5tract left
Geth rakudo/lizmat-WARNINGS: 445c57aabf | (Elizabeth Mattijsen)++ | 3 files
Introduce $*WARNINGS and ENV<RAKU_WARNINGS>

  - Introduces 4 new classes that provide different behaviours for warnings
  - CX::Warn::Quietly - do *not* show warnings, similar to quietly
  - CX::Warn::Fatal - immediately throw a warning as an exception
  - CX::Warn::Verbose - immediately show warnings with complete backtrace
  - CX::Warn::Collect - collect warnings until END, then show with frequencies
... (21 more lines)		 15:22
rakudo: lizmat++ created pull request #5206:
Introduce $*WARNINGS and ENV<RAKU_WARNINGS>		 15:23
lizmat finally got around to doing that, has been bugging me for years 15:24
sjn lizmat: nice! would it be sensible with a ::Collect-like class that you can trigger yourself? (e.g. if a fatal exception happens, you don't get a stack trace, but the previous N non-fatal messages in addition to the fatal one) 15:46
lizmat sure, that's why I made it pluggable 15:47
Nemokosch really good 😄 15:48
Geth rakudo/main: 8db4181942 | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: Make "of" type determination more resilient

For some reason the old code ran fine when used inside the grammar, but died with programmatically built RakuAST::Trait::Of objects.		 16:03
lizmat m: dd (subset Foo).^refinement 16:29
camelia Mu
lizmat m: Q|dd (subset Foo).^refinement|.AST(:run)
camelia Any
lizmat nine: ^^ could that become an issue ?
Geth rakudo/lizmat-WARNINGS: 467ce81b39 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Get rid of debug code, vrurg++
 16:52
rakudo/main: d2c3e9314d | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: default subset.^refinement should be Mu

To make it match what happens using the base grammar		 17:18
rakudo/main: b77f6c44d9 | (Elizabeth Mattijsen)++ | t/12-rakuast/subset.rakutest
RakuAST: add some more RakuAST::Type::Subset tests
 17:33
lizmat ab5tract: did I miss any cases > 17:34
?
tellable6 lizmat, I'll pass your message to ab5tract
18:00 reportable6 left 18:02 reportable6 joined
nine lizmat: 8db4181942 is definitely wrong. PRODUCE-META-OBJECT is meant to be called once. Use .meta-object to access the results 18:10
lizmat nine: ack 18:11
Geth rakudo/main: fb205b31a0 | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: use right method to get type object, nine++
 18:20
20:12 benchable6 left, tellable6 left, quotable6 left, squashable6 left, releasable6 left, statisfiable6 left, notable6 left, committable6 left, coverable6 left, sourceable6 left, nativecallable6 left, greppable6 left, evalable6 left, unicodable6 left, bisectable6 left, reportable6 left, shareable6 left, linkable6 left, bloatable6 left, squashable6 joined 20:13 quotable6 joined, nativecallable6 joined, evalable6 joined, bisectable6 joined, notable6 joined, benchable6 joined, greppable6 joined, bloatable6 joined 20:14 releasable6 joined, linkable6 joined, unicodable6 joined, tellable6 joined, statisfiable6 joined, shareable6 joined, sourceable6 joined 20:15 reportable6 joined, committable6 joined, coverable6 joined 20:46 ab5tract joined
ab5tract o/ 20:55
tellable6 2023-02-14T17:34:26Z #raku-dev <lizmat> ab5tract: did I miss any cases >
ab5tract lizmat: tests look good to me
lizmat cool
ab5tract unless you want to add one specifically for when it's an expression like 5 or /5/
to stretch the wrapper code that is used in those cases 20:56
lizmat ah, yes, that's what is needed, will do 20:57
afk again& 20:58
21:16 codesections left
lizmat m: Q|subset Foo where 5; dd 5 ~~ Foo|.AST(:run) 21:44
camelia ===SORRY!===
Unknown compilation input 'qast'
lizmat ab5tract ^^ 21:45
ab5tract That was working before
lizmat ok, lemme see if I messed that up :-(
hmmm... I guess spectest doesn't test for it ? 21:48
ab5tract it probably does, in that still-failing subset test file
which is overloaded imo
gist.github.com/ab5tract/7f095e93f...4884d2a65e 21:50
^^ lizmat
those are all the test cases I collected
lizmat thanks! 21:51
and these all work on the base grammar, right ?
ab5tract yup
feel free to add to roast, i haven't managed to get around to ceating a PR for it 21:54
lizmat I'd say: just add it :-)
ab5tract I don't think I have push access on roast
lizmat almost anybody has ? 21:58
historically speaking
ab5tract I'm open to having access. But in this case it might be quicker/easier for you to add 22:00
lizmat ab5tract on github
right ?
ab5tract yup
lizmat invite sent
ab5tract thanks! 22:02
lizmat jjatria: ok, so you're going to be able to cope with the change ? 22:03
jjatria lizmat: I made a comment on github.com/rakudo/rakudo/issues/5201. Yeah: I think I can cope with that change
lizmat yeah, saw it... :-) 22:04
jjatria Ah, cool :)
lizmat so I'm gonna mark those modules as "will be fixed" in the blin issue, ok ?
jjatria Sure. I'll merge and let you know when I have a release minted 22:05
lizmat okido thanks!
jjatria Woo~
lizmat ab5tract: confirmed it worked with c17d5b2f2a1 22:18
Nemokosch what dists does Blin check? 22:20
lizmat ab5tract confirmed it worked with 0db0ea5128b03 22:21
(your last commit on subsets) so I borked it
22:21 linkable6 left
ab5tract :( 22:21
22:22 linkable6 joined
lizmat b915dd3a806c11353266 is indeed the breaker 22:30
ab5tract am I crazy or am I unable to use Pair.new in RakuAST code? 22:43
can't do $_ => $value either, dies because it thinks I want to do assignment
lizmat yeah, the grammar is pretty limited, it only knows :foo(42) and :bar<666> 22:44
I think
ab5tract hmm, so there is no way to create a pair that has a variable for a key
lizmat there are RakuAST classes for that, no ? 22:45
found the problem!
ab5tract I need to pass it to EnumHOW
nice!
lizmat running tests... 22:46
ab5tract nine: Any idea how to create a pair with a variable for a key in RakuAST? 22:48
lizmat meh, no spectest fails, but one subset test fail 22:51
will continue looking at this tomorrow
fg 22:52
ab5tract sounds good!
good night lizmat 22:53
looks like I get what I need via nqp::shift(nqp::iterator(%hash)) 23:00
23:13 sena_kun left
jjatria lizmat: done~ 23:13
23:56 ab5tract 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!