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
00:17 pmurias left
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
00:28 dogbert17 left
jnthn Ah, maybe so... 00:28
There's a bit too much going on in there to easily follow it...
00:28 dogbert17 joined
MasterDuke heh, yep 00:28
00:30 hungrydonkey joined
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
01:34 sena_kun joined 01:35 Altai-man_ left
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
01:43 unicodable6 joined, tellable6 joined 01:44 evalable6 joined, linkable6 left
AlexDaniel uh just fixed some bots, they should be back online now 01:46
sorry if this caused any inconvenience :)
01:46 linkable6 joined
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
02:13 ufobat_ joined 02:17 ufobat left
Geth rakudo: 348fa84c34 | Coke++ | src/core.c/Proc/Async.pm6
fix typo in comment
 02:58
03:33 Altai-man_ joined 03:36 sena_kun left 05:34 sena_kun joined 05:35 Altai-man_ left 05:52 cognomin_ joined 05:55 cognominal left 07:33 Altai-man_ joined 07:36 sena_kun left
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
08:34 zostay left, zostay joined 08:35 kawaii left 08:37 kawaii joined 08:43 jmerelo joined
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
08:54 domidumont joined
jmerelo Altai-man_: whenever does work 09:02
09:02 domidumont left 09:06 domidumont joined 09:10 domidumont1 joined 09:14 domidumont left 09:34 sena_kun joined 09:35 Altai-man_ left
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
09:40 domidumont1 left, domidumont joined
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
09:42 domidumont left 09:43 domidumont joined
|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
11:02 domidumont left
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
11:33 Altai-man_ joined 11:35 sena_kun left 12:05 hungryd21 joined 12:06 hungrydonkey left, hungryd21 left, hungrydonkey joined 12:07 hungrydonkey left
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
13:29 lucasb joined 13:34 sena_kun joined 13:36 Altai-man_ left 14:14 MasterDuke left 14:21 jmerelo left 15:33 Altai-man_ joined 15:35 sena_kun left 16:42 jmerelo joined 16:48 patrickb joined 17:21 Kaiepi left, Kaiepi joined
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
17:31 Kaiepi left 17:32 Kaiepi joined 17:34 sena_kun joined 17:35 Altai-man_ left 17:36 domidumont joined
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)
18:08 domidumont left
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.
18:48 MasterDuke joined
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
19:33 Altai-man_ joined 19:35 sena_kun left 20:00 jmerelo left 20:01 Kaiepi left, Kaiepi joined
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
20:13 cognominal joined 20:16 cognomin_ left
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
21:34 sena_kun joined 21:35 Altai-man_ left 22:19 lucasb left 22:21 patrickb left 23:21 MasterDuke left 23:33 Altai-man_ joined 23:35 sena_kun 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!