lucs I just read <github.com/lucs/Test-Selector/pull/3>. 00:21
The pull request mentions blin issue <github.com/rakudo/rakudo/issues/6570>, which mentions my Debugging::Tool and File::TreeBuilder modules, which use Test::Selector.
Is clicking the "Approve workflows to run" in the pull request all that is required to get all things right?
ugexe you need to make a new release of test selector 00:30
with that pr
lucs Ah, okay. 00:33
OK, merged, will update release. 00:34
ugexe thanks
lucs *phew* Done. I suck at git/github. 01:20
02:08 kurahaupo left
Geth ¦ rakudo: coke unassigned from MasterDuke17 Issue blin issue 2026.08 run github.com/rakudo/rakudo/issues/6570 03:08
04:45 kurahaupo joined 04:52 vrurg_ joined 04:55 vrurg left 05:07 sergot left 05:09 sergot joined 05:59 vrurg_ left 08:13 lizmat joined 09:19 AlexDaniel joined 09:26 tellable6 left, sourceable6 left, bloatable6 left, evalable6 left, bisectable6 left, benchable6 left, notable6 left, nativecallable6 left, committable6 left, linkable6 left, unicodable6 left, releasable6 left, greppable6 left, coverable6 left, huggable6 left, quotable6 left, shareable6 left 09:30 bisectable6 joined 09:31 bloatable6 joined, huggable6 joined, benchable6 joined, releasable6 joined, quotable6 joined 09:32 tellable6 joined, unicodable6 joined, nativecallable6 joined, greppable6 joined, sourceable6 joined, linkable6 joined 09:33 shareable6 joined, evalable6 joined, committable6 joined, coverable6 joined 09:34 notable6 joined 09:57 lizmat left 10:01 sivoais left 10:05 sivoais joined
AlexDaniel c: a5c48846b310c4e79e785b473f32dc928776d47f say 42 11:20
committable6 AlexDaniel, ¦a5c4884: «Cannot test this commit (Broken archive)»
AlexDaniel c: a5c48846b310c4e79e785b473f32dc928776d47f say 42 11:41
committable6 AlexDaniel, ¦a5c4884: «42␤»
AlexDaniel [Coke]: back to normal :)
12:03 sergot left 12:04 sergot joined 12:58 finanalyst joined 13:10 vrurg joined 13:25 AlexDaniel left
[Coke] alexDaniel++ 16:16
ugexe should `is rw` allow changing the type? 16:32
m: sub f(Str $x is rw) { $x = 43 }; my $c = "s"; f($c); say $c
camelia 43
ugexe i have a branch that makes a bunch more type checks compile time errors instead of runtime and the above example is one thing i'm not entirely sure about 16:33
[Coke] my 2c is that it would allow it to change, but that it should have whatever restrictions are in the sig. 16:40
ugexe yeah to be clear i'm talking about $x's type changing not $c
[Coke] yes, $x= 16:41
er, $x
ugexe and to be clear what do you mean by "have whatever restrictions are in the sig"? do you mean the restrictions should be applied when the function is called (i.e. f(1) is illegal)? or that the type restriction should also apply when it does $x = 43? 16:46
m: class Foo { has Int $.x is rw = 42; method bar { $!x = "fourty two"; }; }; my $o = Foo.new; say $o.x; say $o.bar 16:54
camelia 42
Type check failed in assignment to $!x; expected Int but got Str ("fourty two")
in method bar at <tmp> line 1
in block <unit> at <tmp> line 1
ugexe that makes me think the example i gave earlier should be an error
japhb ugexe: I'm not positive, but I think [Coke] was saying that `$x = 43` would be an error, because it's not a Str or subclass thereof. But `$x = <43>` or `$x = val(43)` could work, since IntStr isa Str. 18:56
(Even though the original argument passed was a proper Str) 18:57
ugexe yeah thats what i would expect 19:00
[Coke] +1 19:02
19:08 lizmat joined 22:20 finanalyst left 23:54 kurahaupo left 23:55 kurahaupo joined