vrurg jnthn: but rw is simply reset by 'is readonly'. To my view, just $!rw should be sufficient. I'll try getting rid of $!ro and see what happens. 00:07
MasterDuke m: multi infix:<==>(Int $a, 2) { say "is $a equal to 2?"; use nqp; nqp::iseq_I($a, 2); }; say 4 == 2; sub a($a where 1|2) { $a }; say a(1); say a(2)
camelia is 4 equal to 2?
0
1
2
MasterDuke m: multi infix:<==>(Int $a, 73786976294838206464) { say "is $a equal to a bigint?"; use nqp; nqp::iseq_I($a, 73786976294838206464); }; say 4 == 73786976294838206464; sub a($a where 1|73786976294838206464) { $a }; say a(1); say a(73786976294838206464) 00:09
camelia is 4 equal to a bigint?
0
1
73786976294838206464
MasterDuke it looks to me like operator overloading already isn't being respected? 00:11
m: my sub infix:<==>(Int $a, Int $b) { say "is $a equal to a $b"; use nqp; nqp::iseq_I($a, $b); }; say 4 == 73786976294838206464; sub a($a where 1|73786976294838206464) { $a }; say a(1); say a(73786976294838206464) 00:13
camelia is 4 equal to a 73786976294838206464
0
1
73786976294838206464
jnthn MasterDuke: Ah, yes, that's 'cus you're not maintaining smart-match semantics, I guess... 00:25
m: say "abc" ~~ 1
camelia False
jnthn MasterDuke: I'd probably just emit method calls to .ACCEPTS and let inlining DTRT
Well, though, it depends if you know you should be smart-matching there 00:26
vrurg: Worth a try to remove the `$!ro`
MasterDuke is that what this block right at the end does? github.com/MasterDuke17/rakudo/com...2991-L2999 00:27
jnthn Ah, maybe so... 00:28
There's a bit too much going on in there to easily follow it...
MasterDuke heh, yep 00:28
MasterDuke but i'm just building a chain of iseqs, so not sure why/where that str is getting decont_i'ed 00:30
this is what it looks like for 1|"abc", gist.github.com/MasterDuke17/a75a3...8ccc518ce7 00:31
jnthn That's not doing any type guarding 00:35
So it's just trying to unbox the lowered parameter to an integer 00:36
You'd need to do the "is it the right type" against every junction argument (or lift it)
vrurg jnthn: 'also is readonly' provides a good reason for both ro and rw to exists. :) 00:45
jnthn :) 00:49
sleep time o/
MasterDuke later... 00:50
Geth roast/rakudo_3495: f63ef08b6a | (Vadim Belman)++ | 2 files
Added tests for late applied `also is rw`

No matter when `is rw` is applied, attributes without explicit `is readonly` trait have to repsect it:
  ```
class C { ... (7 more lines)		 01:35
AlexDaniel uh just fixed some bots, they should be back online now 01:46
sorry if this caused any inconvenience :)
AlexDaniel this month I won't be able to pay any attention to the stuff around here, so yell very loudly at me if something is broken :) 01:46
Geth rakudo: 348fa84c34 | Coke++ | src/core.c/Proc/Async.pm6
fix typo in comment
 02:58
Altai-man_ releasable6, status 08:27
releasable6 Altai-man_, Next release in ≈3 days and ≈10 hours. 4 blockers. 0 out of 237 commits logged
Altai-man_, Details: gist.github.com/67be816cfb4791d11f...9edb38af0a
Altai-man_ release: Blin is clean, 1)spec is blocked by github.com/rakudo/rakudo/issues/3492 2)is github.com/MoarVM/MoarVM/issues/1237 still reliable on macos? 3)any progress on github.com/MoarVM/MoarVM/issues/1234 ? 4)github.com/rakudo/rakudo/issues/3345 probably wants attention of jnthn. 08:31
releasable6 Altai-man_, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Releasable
Altai-man_ once those 4 are fixed, we will safely release this week given nothing new pops out 08:32
jmerelo Any idea why this happens? stackoverflow.com/questions/tagged/raku 08:43
Sorry, that's not it (it's the one on the top, anyway) stackoverflow.com/questions/602949...ifications
Altai-man_ jmerelo, can you rewrite tap as whenever and check if the error disappears? 08:45
I think a block passed to a tap doesn't recognize it is lexical to the outer supply, maybe?
jmerelo Altai-man_: it does with a "normal" supply. 08:48
Altai-man_ well, as a next thing we want to check if that's a bug or intended, which I don't know. 08:49
jmerelo Altai-man_: whenever does work 09:02
lizmat Files=1302, Tests=111141, 210 wallclock secs (28.55 usr 8.40 sys + 2939.34 cusr 281.14 csys = 3257.43 CPU) 09:37
this was *without* the $?FILE fix, so it most definitely affects the spectest performance in a bad way
I think we need a better way to fix this and am reverting the fix now 09:38
Geth rakudo: 58e8fb1506 | (Elizabeth Mattijsen)++ | 3 files
Revert the $?FILE cleanup

It badly affects spectest performance. This could have several reasons but I suspect it is actually the extra work that CallFrame has to do. Or it is that it somehow causes test libraries to have to be recompiled again and again. Anyways, it was a hack, and we need a better way to convey what the current file is cleanly, and how to provide better support for execuction errors from CUR::I installed files.		 09:41
|Tux| Rakudo version 2020.01-238-g58e8fb150 - MoarVM version 2020.01.1-39-g657b536cf
csv-ip5xs0.713 - 0.720
csv-ip5xs-205.681 - 5.821
csv-parser23.006 - 23.381
csv-test-xs-200.365 - 0.367
test7.097 - 7.298
test-t1.740 - 1.751
test-t --race0.802 - 0.808
test-t-2029.574 - 30.462
test-t-20 --race8.638 - 8.941
 10:33
releasable6 Next release in ≈3 days and ≈7 hours. 4 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
jmerelo Tomorrow the GSoC funded organizations will be announced 11:21
Probably we'll get a sneak peek today (if TPF is going to be funded)
sena_kun crosses fingers 11:24
Kaiepi can someone review github.com/rakudo/rakudo/pull/3491 ? i want to get it in before people start using unix socket support 13:13
tellable6 2020-02-08T19:55:29Z #raku <AlexDaniel> Kaiepi: can you take a look at? github.com/Raku/old-issue-tracker/issues/6342
2020-02-08T19:56:05Z #raku <AlexDaniel> Kaiepi: oops, misplaced question mark, sry :) Anyway it's just an old ticket that maybe we can close or something
2020-02-08T19:59:29Z #raku <AlexDaniel> Kaiepi: also: github.com/Raku/old-issue-tracker/issues/6399
patrickb releasable: status 17:29
releasable6 patrickb, Next release in ≈3 days and ≈1 hour. 4 blockers. 0 out of 238 commits logged
patrickb, Details: gist.github.com/fea1e3574a9a3ac809...ebcbfaef9c
Altai-man_ blockers, blockers... 17:30
lizmat m: my $a = Failure.new; $a.not; dd $a # this feels like a weird outcome 17:41
camelia Failure $a = &CORE::infix:<orelse>(Failure.new(exception => X::AdHoc.new(payload => "Failed"), backtrace => Backtrace.new), *.self)
jmerelo The new-old gitignore for Raku has been merged github.com/github/gitignore/pull/3...-361318699 18:12
If past is a guide, it will take one year to take it to production 18:13
But then, only name and comments have changed from the old one, so maybe not.
Stay tuned in the .gitignore dropdown to check when Raku shows up.
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Should $foo ~~ Failure mark Failure in $foo as handled? github.com/Raku/problem-solving/issues/161 19:21
MasterDuke if there's no objection, i'm going to merge github.com/rakudo/rakudo/pull/3488 soon 19:31
lizmat MasterDuke: maybe wait until after the 2020.02 release ? 19:32
MasterDuke oh right, that should be this weekend, right?
lizmat yes... feels like this could use some more time to be out in the wild before being in a release 19:33
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Allow single-element Map/Hash to be treated as a Pair github.com/Raku/problem-solving/issues/162 20:11
MasterDuke jnthn: how does this look? github.com/MasterDuke17/rakudo/com...d9d9b34702 20:19
i can't get it to error (except the expected errors if you pass something that never matches) 20:20
jnthn: oops, github.com/MasterDuke17/rakudo/com...b27aeaff5a 21:20
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Implement Adverb::Eject in core github.com/Raku/problem-solving/issues/163 21:24

Powered by Cro and the Raku® Programming Language.

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

Thank you!