🦋 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.
Geth rakudo: 2colours++ created pull request #5182:
Fix recent regression on storing Maps
00:00
Geth rakudo/complex-sign: 3504a40313 | (Will Coleda)++ | src/core.e/Complex.pm6
Handle sign(0), add signature
02:18
Geth rakudo: coke self-unassigned Any.print-nl is broken github.com/rakudo/rakudo/issues/2713
usev6++ created pull request #5183: Streamline comments about CORE-SETTING-REV
03:42
nine ab5tract: instead if nqp::can(..., 'resolution'), you want nqp::istype($!type, RakuAST::Lookup) 07:30
tellable6 nine, I'll pass your message to ab5tract
nine ab5tract: but then, $!type should already be a RakuAST::Type and $!type.meta should give you the type object you're after 07:35
tellable6 nine, I'll pass your message to ab5tract
ab5tract nine: good point! The code looks better now 10:11
tellable6 2023-02-04T07:30:52Z #raku-dev <nine> ab5tract: instead if nqp::can(..., 'resolution'), you want nqp::istype($!type, RakuAST::Lookup)
2023-02-04T07:35:08Z #raku-dev <nine> ab5tract: but then, $!type should already be a RakuAST::Type and $!type.meta should give you the type object you're after
ab5tract Now for the mysterious issue with whatevercodes :) 10:22
I have to say it though.... "all that, for one stinking subtest??" ;)
There must be a clue here... '-> Int $i where * == 5 { say $i }(5)' --> "This type cannot unbox to a native integer: P6opaque, WhateverCode" 10:31
lizmat the --ll-exception trace doesn't give a clue ? 10:32
nine I'd probably look at the QAST 10:40
ab5tract not really, no. This should be happening in main with the new frontend too
looks like one of the major changes is that the relevant ParamTypeCheck node (?) has a WVal of Block in the new frontend and a WVal of WhateverCode in the old frontend 10:47
nine Huh....I'd think that the Block is more correct :D 10:48
Nemokosch could you please take a look at github.com/rakudo/rakudo/pull/5182 ? It should fix a release blocker thinko. We are not in a hurry but yeah, it would be good to get a clean sheet with a known problem 10:50
ab5tract yeah, might be. it's our little wrapper that we apply around the expression, anyway. so all it would do is add a single extra layer. conceptually this should work
Geth rakudo/main: 5ed14bc468 | (Márton Polgár)++ (committed using GitHub Web editor) | 2 files
Fix recent regression on storing Maps (#5182)

The commit that was meant to fix storage of "hash objects" into Hashes had a serious thinko: after checking for Maps, it invoked a method defined on Hashes only. This meant that after the changes
my %problem is Map = :foo; ... (9 more lines)
10:51
ab5tract I also see some differences in attributes, not sure how relevant they are.. ' - QAST::WVal(Block :cuid(2)) :uninstall_if_immediately_used<?> :past_block<?> :code_object<?>' in old, just 'QAST::WVal(Block)` in the new 10:52
nine You should be able to ignore those 10:57
ab5tract nine: I think ApplyInfix does need some special casing. observe: ''say { * == 5 }(5)' --> "WhateverCode.new"; ''say { * == 5 }(5)(5)'' --> True
we are applying an extra level of wrapping 10:58
also: nine++; confirming my suspicions
nine But, but that looks correct! In fact the old frontend tells you that it would create such a thing but that it would be seriously odd to want that: 11:03
Malformed double closure; WhateverCode is already a closure without curlies, so either remove the curlies or use valid parameter syntax instead of *
ab5tract oh yes, that behavior is correct! It's also what we are doing programmatically by re-wrapping the ApplyInfix expression 11:23
is it not?
ie, instead of the equivalent to '(* == 5).ACCEPTS(5)', we have '{ * == 5 }.ACCEPTS(5)', which returns a WhateverCode, which either explodes or passes the next call to .Bool gracefully 11:25
Ah, nevermind... we are making something closer to this, I think: '{ (* == 5).ACCEPTS($_).Bool }(5)' 11:28
dang 11:29
nine lizmat: hah! Now I know which additional test passes. Of course it's the new nqp.rakutest 12:03
lizmat ah, so it was already at 127 ? 12:09
Geth rakudo/main: d824e6d24c | (Stefan Seifert)++ | 2 files
RakuAST: support stacking of type derivations

We already supported derived types like Int:D or Int(Cool), but could not combine derivations like Int:D(Cool). Now we can.
nine yes
ab5tract what does '- v' mean in QAST output? I see it in QAST generated by the old frontend 12:16
lizmat ok, this cost me 3 hours to figure out
don't use :$!name in code in src/Raku/ast
it produces the weirdest compilation errors at the wrong place 12:17
use :name($!name) instead, TIL
ab5tract lizmat++ 12:19
grrr... this case also fails (eg fails to fail) in the new frontend: 'module M { my subset F of Int where * ~~ 5 }; say my M::F $f = 6' 12:27
it should bail, not knowing what 'M::F' is 12:28
should there be a test file for all these seemingly untested subset thingies?
lizmat m: module M { my subset F of Int where * ~~ 5 }; say my M::F $f = 6 12:33
camelia ===SORRY!===
Type 'M::F' is not declared
at <tmp>:1
------> set F of Int where * ~~ 5 }; say my M::F⏏ $f = 6
Malformed my
at <tmp>:1
------> bset F of Int where * ~~ 5 }; say my M::⏏F $f = 6
lizmat m: module M { subset F of Int where * ~~ 5 }; say my M::F $f = 6
camelia Type check failed in assignment to $f; expected M::F but got Int (6)
in block <unit> at <tmp> line 1
lizmat perhaps the scope is missing on M::F in the new backend ? 12:34
so, here's an idea wrt pragmas: 12:35
why don't we populate Braid.$!slangs with all possible pragmas, but set to 0 ? 12:37
ab5tract the scope is as defined as it needed to be for the default 'our' to work. not sure what else needs to be glued together / explicitly defined 12:38
lizmat neither 12:39
ab5tract I have some custom code in "IMPL-INSTALL-SUBSET" and I expect that is where things are going wrong
making it 100% match (with some small tweaks) the IMPL-INSTALL-PACKAGE from package.rakumod did not fix anything.. 12:47
bartolin bisectable6: my class A {}; my class B {}; my class C is B is A {}; multi f(A) { "A" }; multi f(B) { "B" }; sub g(A $x) { say f($x) }; g(C.new) ## github.com/Raku/old-issue-tracker/issues/2874 13:11
bisectable6 bartolin, Will bisect the whole range automagically because no endpoints were provided, hang tight
bartolin, Output on all releases: gist.github.com/664478b2f00fb7873d...25ab407abb
bartolin, Bisecting by output (old=2020.08.2 new=2020.09) because on both starting points the exit code is 1
bartolin, bisect log: gist.github.com/da9e43abbbc2e937d8...51d666ee14 13:12
bartolin, (2020-08-20) github.com/rakudo/rakudo/commit/99...70d88e5b81
bartolin, Bisecting by output (old=2017.12 new=2018.01) because on both starting points the exit code is 1
bartolin, bisect log: gist.github.com/94ccce845886e5259a...58be43539b
bartolin, (2017-12-23) github.com/rakudo/rakudo/commit/6d...cd47249a05
bartolin, Bisecting by exit code (old=2017.01 new=2017.02). Old exit code: 0
bartolin, bisect log: gist.github.com/2d3079fd9d7e90b084...a4436d52a1
bartolin, (2017-01-31) github.com/rakudo/rakudo/commit/f8...e4bac50dca
bartolin, Output on all releases and bisected commits: gist.github.com/2f3355d1bed8c97b71...81967c499e 13:13
Nemokosch bartolin++ for organizing issues 13:53
bartolin thanks. (It feels a bit like a drop in the ocean, but that's only a pesky temporary fealing ;)) 13:57
*feeling
Nemokosch It helps with not getting completely lost and buried with incomprehensible issues 🙂 14:02
el gatito (** advocate) how does the raku parser deal with operators afaik raku uses a recursive descent parser and it can’t deal with operators (left recursion specifically) 14:40
nine Your IMPL-INSTALL-SUBSET needs to check self.scope to figure out what exactly it has to do 15:03
ab5tract right, it's the what it has to do part that eludes me. I feel like I've gleaned as much as I can from the package.rakumod example 15:25
nine Maybe you actually shouldn't take too much inspiration from package.rakumod as for one your job is a lot easier and two, I'm quite sure that code is anything but correct. It's mostly guess work in the horrible area of (potentially multi part) package name and stashes. 15:42
If it's my scoped, generate the lexical, if it's our scoped, add it to the current package's stash.
ab5tract That's essentially what I'm already doing, though I've just pushed a cleanup. 15:57
Only difference is I need to always install the lexical, otherwise RakuAST::Type::Simple doesn't resolve 15:58
and what about 'subset M::F where 5; my M::F $f = 5;' -- doesn't an implicit module (or package) 'M' get created when this is done? currently in the ast frontend it throws "malformed my" 16:00
nine Oh indeed. Makes me wonder whether subset may actually need 100 % of package's complexity 16:02
E.g. class Foo::Bar { }; subset Foo where * == 5; # in this case the subset Foo should replace the packgae stub Foo including stealing it's WHO 16:03
ab5tract I tried with a full copy-paste treatment (aside from the lexical installation, where I do a VarDeclaration instead of a LexicalPackage) from the package code but it didn't fix my issue with 16:05
*issue with 'my' subsets being available oustide their module
but yeah, it definitely needs that extra complexity to do what you are describing 16:06
nine Funnily I'm currently investigating a similar issue in the other direction: { class Foo { } }; Foo.new does not find the our-scoped Foo, because it looks like the resolver doesn't actually look in any packages 16:07
ab5tract well well 16:09
what happens when a WHO is stolen, by the way? does that mean that `Foo::Bar` would still exist? 16:10
nine Yes, that's the point of stealing. Basically the stub package is replaced in the stash hierarchy with the more interesting one you just declared 16:11
ab5tract gotcha
nine: I've built up a corpus of subset syntax / behavior tests. would it make sense for them to become part of the corpus? 16:44
wow, I guess because I rarely use 'corpus', I got excited and used it twice. Should the small corpus I've just created be added to the Grand Corpus of Raku? 16:45
nine Sure, add them to roast 16:46
ab5tract they might already be in there somewhere, lol. what a massive suite we have 16:51
alright, I'm out for today. Thanks all for your help on getting subsets to work 16:52
o/
nine Thanks for working on it :) 16:56
nine Raku is such a lexical package that to this date, the RakuAST resolver does not actually know how to even look up symbols in packages 17:48
patrickb o/ 20:00
Geth rakudo/main: 40a8d03283 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: refactor handling of pragma and isms

  - create new RakUAST::Pragma and RakuAST::Isms class
  - create those from inside RakuAST::Statement::Use if applicable
  - move handling out of ::Use into the classes
  - add deparsing for these classes
20:01
Nemokosch what's up, Patrick?
patrickb I have a potential fix for the Supply/whenever issue I'm working on. All tests and spectest pass, except one. IMHO the outcome is technically correct, and the tests wrong. Can someone verify? The failing test is: gist.github.com/patrickbkr/b5295a5...f60ae57cbc
The docs say that `zip` is done as soon as any of the given supplies is done. As the order in which the supplies are processed is undefined, the outcome can be a shorter list or even an empty one. With my changes it's the empty one (as it processes all the messages of the first supply first). 20:03
Nemokosch it's weird that there is such a deterministic test for something conceptually non-deterministic, at least... 20:07
no matter the result imo
and exactly because it makes changes harder at low-level, relying on accidental results 20:08
Geth Raku-Data-MessagePack/master: 10 commits pushed by (Polgár Márton)++
review: github.com/raku-community-modules/...384e78ba34
20:16
lizmat Nemokosch perhaps also change the default branch to "main" :-) 20:31
Nemokosch heh, feel free to. That's definitely not on my list 🏳️ 20:39
Geth roast: f630edabeb | (Christian Bartolomäus)++ | S06-signature/optional.t
[JVM] Unfudge tests for typed option @/% params

This has been fixed with
  github.com/rakudo/rakudo/commit/49facdc03c.
20:46
roast: 0d696f42a5 | (Christian Bartolomäus)++ | 2 files
[JVM] Fudge some newly failing tests
lizmat Nemokosch: are you done with Data::MessagePack for now? don't want to interfere 20:47
tellable6 lizmat, I'll pass your message to Nemokosch
Nemokosch yes, I'd hope the main goal has been achieved for now 20:48
lizmat oki, then I'll change the default branch
Nemokosch do as you wish 20:49
from now on, it's all up to users, which I am not, for better or worse
lizmat oki
Geth Data-MessagePack/main: 62 commits pushed by 8 authors
review: github.com/raku-community-modules/...384e78ba34
20:50
lizmat also, removed the redundant "Raku-" prefix from the repo name 20:50
Nemokosch okay, just make sure it stays consistent with metadata (or well, vice versa) 20:54
by the way, any opinion on patrickb's test issue? so that it doesn't get buried 20:55
okay, it's also noted at github.com/Raku/problem-solving/issues/364 20:56
Geth rakudo/main: e45436ef06 | (Elizabeth Mattijsen)++ | 2 files
Abstract the producing of Nil

Several classes will always produce Nil as their result. Abstract that logic into a single role to increase the amount of DRY.
21:14
lizmat and that concludes my hacking for today& 21:15
Geth rakudo: shmup++ created pull request #5185:
Fix minor non-comment typos
23:57