02:15 MasterDuke left 02:47 kvw_5_ joined 02:50 kvw_5 left 03:20 leont left 04:20 linkable6 left, evalable6 left 04:21 evalable6 joined 04:22 linkable6 joined 04:28 sortiz joined
sortiz lizmat: Now that Map.iterator is multi, wouldn't it be a good idea to short-circuit Map.pairs? 04:46
05:37 japhb joined 06:05 djinni` left 06:10 djinni` joined 07:15 sortiz left 07:35 epony left 07:46 MasterDuke joined 07:55 domidumont joined 08:31 epony joined 08:53 leont joined
nine lizmat: apparently those inlining tests also fail in my development environment, which is good, as I can have a closer look. And indeed, I get # Failed test 'Was AT-KEY inlined?' at t/09-moar/11-inline-hash-key.t line 15 when the inline report lists "2x unspecialized AT-KEY BB(7867, 270 bytes) -> postcircumfix:<{ }> BB(2490)" in the successful inlines 09:07
tellable6 2021-02-21T23:08:37Z #raku <raiph> nine MasterDuke suggested I ask you colabti.org/irclogger/irclogger_lo...02-21#l329
nine Got that by adding a "or diag $SIL.report" after the test 09:08
El_Che that 11-inline-hash-key.t is certainly the winner in failed tests, I see it regularly 09:09
(I have been updating the flapper metaticket, I hope no one objects) 09:11
09:18 sena_kun left 09:27 sena_kun joined
lizmat nine++ 09:42
nine: are there other prefixes than "unspecialized" that can be used there ? 09:43
nine I don't know. I didn't know we had an inline log until I saw it used in MoarVM::SIL :) 09:46
lizmat aha... ok, well, I guess it is possible for something to get inlined before spesh got to it 09:49
fix for that coming up
nine Looks like "unspecialized " is the only one: github.com/MoarVM/MoarVM/blob/mast...mize.c#L21 09:50
Geth rakudo: f860950410 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod
Add BB.specialized attribute, fix name checking

Apparently a BB can be inlined *without* it being specializd, and that is reported in the log. Unfortunately, this wasn't taken into account when looking for names, so name checks (like the t/09-moar/*inline*.t tests) would report failure, when in fact the name checked for *was* inlined, but without being specialized.
  nine++ for tracking the source of these flappers
09:52
MasterDuke at HEAD of master/master/master i still get some inline test fails (t/09-moar/14-inline-comparators-str.t) with no other system load. with moarvm on my always_log_decont branch (rebased to HEAD of master) i get a bunch of additional inline test fails 10:11
lizmat yeah, I just realized there's an off-buy-one error in the code 10:13
*by 10:14
MasterDuke buy one, get none free 10:16
Geth rakudo: b0f7ce4ed4 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod
Make "unspecialized" test more robust
10:20
nine lizmat: typo: unspeciaized 10:26
also white space on the line before
lizmat argh... must not be awake enough yet 10:28
Geth rakudo: aed69bb222 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod
Properly spell specialized *sigh*
10:29
10:33 MasterDuke left 10:34 MasterDuke joined
MasterDuke huh, still getting that t/09-moar/14-inline-comparators-str.t fail at HEAD 10:35
lizmat MasterDuke: could you gist the report when there's a fail ? 10:40
nine same here 10:41
that's how I noticed the typo
lizmat thing is, I can't get it to fail on my machine
it's hard to write tests for cases that you can't get to fail personally :-( 10:42
MasterDuke gist.github.com/MasterDuke17/d74f0...5e0e2d83f2
nine MasterDuke: does it still fail with the spelling fix? 10:43
The first version spelled it correctly but used the wrong offset in substr, the second version introduced the typo, the third is the charm
MasterDuke yeah, i'm at 2021.02-9-gaed69bb22
lizmat sorry for this Monday morning mess... 10:44
something more serious that broke in 2021.02
m: (1..10)[1,^Inf]
camelia (timeout) 10:45
lizmat and probably broken by me
I will look into this after the RWN
MasterDuke committable6: 2020.12 (1..10)[1,^Inf] 10:50
committable6 MasterDuke, ¦2020.12: «»
AlexDaniel` hugs Altai-man_ 10:51
any reason not to bisect it, by the way? 10:52
bisect: old=2020.12 (1..10)[1,^Inf]
bisectable6 AlexDaniel`, Bisecting by exit signal (old=2020.12 new=aed69bb). Old exit signal: 0 (None)
AlexDaniel`, bisect log: gist.github.com/3968a742df81518e74...3c22331cce 10:53
AlexDaniel`, (2021-01-08) github.com/rakudo/rakudo/commit/ca...43e8026df1
lizmat MasterDuke: I know where the problem is, just not how to easily fix it
m: dd (1..10)[lazy 1,^Inf] 10:54
camelia (2, (1, 2, 3, 4, 5, 6, 7, 8, 9, 10))
lizmat m: dd (1..10)[1,^Inf]
MasterDuke huh
camelia (timeout)
lizmat as soon as a lazy list is found, it should switch to lazy semantics, which means: stop when the source has run out
by making the outer list of indexes lazy, it will apply lazy semantics and do the right thing 10:55
10:56 [Tux] left 10:59 linkable6 left, [Tux] joined 11:00 linkable6 joined
dogbert11 R#4216 11:01
11:01 linkable6 left
dogbert11 wut 11:01
very strange 11:02
11:04 linkable6 joined 12:29 JRaspass joined
Geth rakudo: lizmat self-assigned Test t/78_fragment.t in Tux CSV module hangs github.com/rakudo/rakudo/issues/4216
655f1ac2af | (Elizabeth Mattijsen)++ | 3 files
12:31
nine lizmat: still seeing a Failed test 'Was infix:<eq> inlined?' when building a package. This time it really doesn't seem to get inlined and got refused instead: 13:35
[ 101s] # 3x infix:<eq> BB(4786, 234 bytes) -> abs2rel BB(12041):
[ 101s] # target has a :noinline instruction - ins: speshresolve
MasterDuke that's what i get also
nine When it does succeed, it's: 2x infix:<eq> BB(4786, 68 bytes) -> abs2rel BB(12041) 13:40
But wait...that doesn't have anything to do with the test code! 13:41
MasterDuke yeah, was wondering why abs2rel was involved there
lizmat perhaps that fixes that ?? ^^
nine The actual test code would look like this: infix:<ne> BB(4788, 68 bytes) -> BB(3)
lizmat: have you checked the output? 13:42
lizmat infix:<leg> BB(4784, 174 bytes) -> BB(9) 13:43
infix:<eq> BB(4786, 68 bytes) -> BB(3)
infix:<ne> BB(4788, 68 bytes) -> BB(4)
infix:<lt> BB(4790, 68 bytes) -> BB(7)
infix:<le> BB(4792, 68 bytes) -> BB(8)
infix:<gt> BB(4794, 68 bytes) -> BB(5)
infix:<ge> BB(4796, 68 bytes) -> BB(6)
after the latest change
nine # 2x infix:<eq> BB(4786, 68 bytes) -> abs2rel BB(12041)
# infix:<ne> BB(4788, 68 bytes) -> BB(4)
# infix:<lt> BB(4790, 68 bytes) -> BB(7)
# infix:<le> BB(4792, 68 bytes) -> BB(8)
# infix:<gt> BB(4794, 68 bytes) -> BB(5)
# infix:<ge> BB(4796, 68 bytes) -> BB(6)
lizmat I think the BB numbers check out actually now
hmmm... perhaps I should make each op test in a separate sub and have it check the name of the BB inlined into? 13:46
13:48 cog__ left
nine That wouldn't fix that infix:<eq> just doesn't get inlined in this case 13:51
But it would make the test more robust and prevent false negatives
lizmat linner& 13:53
14:09 cog joined
Geth rakudo: MasterDuke17++ created pull request #4217:
Fix memory leak in runner
14:12
lizmat notable6: weekly 14:30
notable6 lizmat, 1 note: 2021-02-21T14:08:51Z <Altai-man_>: twitter.com/koto_san_kana/status/1...0431765507
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2021-02-22T14:30:25Z”
Geth rakudo: 18735ae9a8 | (Daniel Green)++ | src/vm/moar/runner/main.c
Fix memory leak in runner

If the `(PERL6|RAKUDO)_HOME` env var is set, `rakudo_home` is malloced, but wasn't being freed.
14:50
rakudo: d58402c7c0 | MasterDuke17++ (committed using GitHub Web editor) | src/vm/moar/runner/main.c
Merge pull request #4217 from MasterDuke17/fix_memory_leak_in_runner

Fix memory leak in runner
14:57 JRaspass left
lizmat awww... /me has to remove an entry from the RWN :-) 15:12
MasterDuke heh, i suspect there will still be enough content 15:18
15:25 maggotbrain left
lizmat and another Rakudo Weekly hits the Net: rakudoweekly.blog/2021/02/22/2021-08-first-21/ 15:37
15:43 maggotbrain joined
vrurg_ lizmat: BTW, they seemingly heard your complains. I saw in the news that the latest Safari is gaining support for webm. :) 15:50
dogbert11 MasterDuke: it still fails. 15:54
MasterDuke yeah, i was just looking at a corefile from coredumpctl. it pointed to github.com/MoarVM/MoarVM/blob/mast...rker.c#L24 which is annoying because i doesn't point out the line inside the macro 16:00
16:37 MasterDuke left
nine MasterDuke that --full-cleanup segfault looks familiar 16:48
16:53 donaldh joined 16:57 JRaspass joined
nine codesections: that re-checking of dependencies you mentioned in stackoverflow.com/questions/662106...rtup-times looks a bit fishy. It really should do that only once and write a .repo-id file. Would be worth investigating why it doesn't. 17:04
17:16 donaldh left
codesections nine++ 17:23
s/ //
17:45 domidumont left 17:51 domidumont joined 18:01 domidumont left
nine codesections: the bad news is that it's you who ought to do that digging :D These things typically depend on the system they're running on 18:08
But I'm happy to assist
lizmat bisectable6: dd (1..10)[lazy 1,(8..12)]
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/283df1d7053c84ac30...f7ccdb1544
lizmat, Bisecting by output (old=2020.12 new=2021.02) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/83a91a97f13ba54eab...60ae062b02 18:09
lizmat, (2021-01-08) github.com/rakudo/rakudo/commit/ca...43e8026df1
lizmat, Output on all releases and bisected commits: gist.github.com/5a099f66448ab54f42...8e8f14a44f
lizmat yeah, what I feared: the old version was buggy as well
m: dd (1..10)[lazy 1,(8..12)]
camelia (2, (9, 10))
lizmat Now, I would have expected that the lazy semantics would *not* carry over into the non-lazy sublist 18:10
m: dd (1..10)[1,(8..12),3] 18:12
camelia (2, (9, 10, Nil, Nil, Nil), 4)
lizmat Looks like the fix for (1..10)[1,^inf] is going to take some refactoring, but in the end, it should reduce the footprint of array slicing on disk 18:18
18:36 Xliff joined
Xliff \o 18:36
tellable6 hey Xliff, you have a message: gist.github.com/21453045be32ce55dd...7fafae7828
Xliff ,tell patrickb Ah, piffle! Thanks for the update. 18:37
Since there doesn't seem to be a #comma channel, can someone tell me how to set the Raku SDK in comma? 18:38
sena_kun Xliff, `File -> Project Structure -> ...` 18:43
Then it should be more or less obvious. If it does not do the auto-detection bit, you need to point it to the directory where `raku` binary is present
Usually its `bin` directory of where your installation lives.
Xliff sena_kun++ # Thanks! 19:12
sena_kun yw
19:48 MasterDuke joined 19:50 JRaspass left
Geth rakudo: 5eeddd37fa | (Elizabeth Mattijsen)++ | 4 files
Fix for #4216

It turned out that a lazy iterable as part of a non lazy list of indexes in a slice, had the possibility of hanging because eager semantics where being used on the lazy iterator, e.g. in `(1..10)[1,^Inf]`
This commit removes all of the Array::Slice classes that existed for ... (20 more lines)
20:08
20:08 linkable6 left
lizmat this also unbreaks Text::CSV 20:08
20:09 linkable6 joined
Geth roast: 187d894660 | (Elizabeth Mattijsen)++ | S09-subscript/slice.t
Mark failing test as todo for now

The semantics of a lazy list slipped into indexes of an array slice, appear to be assuming that the laziness of the Slip would actually influence the laziness of the outer sequence. I don't believe this to be sane semantics.
See: github.com/rakudo/rakudo/commit/5eeddd37fa
20:12
lizmat sena_kun: not sure this warrants a point release, but if you want, you can :-) 20:13
El_Che broken new feature: no dot release, newly broken existing feature: a dot release could unbreak real life code 20:39
nine Holy cow, spesh is smart. It actually notices that we're comparing two string literals and that they won't ever be equal, so it removes the whole equality check 20:48
MasterDuke nice. isn't that the optimization i recently un-disabled? 20:50
Geth nqp: MasterDuke17++ created pull request #696:
Support some missing Rakudo command line flags
20:56
sena_kun sigh, I cannot easily cherry-pick the commit to the release branch. 21:22
deleted by us: src/core.c/Array/Slice.pm6
deleted by us: src/core.c/Rakudo/Internals/PostcircumfixAdverbs.pm6
both modified: src/core.c/array_slice.pm6
deleted by us: tools/build/makeARRAY_SLICE_ACCESS.raku
Oh no, appveyor is failing all the time cause of the inlining tests. 21:24
Geth rakudo: a5ca53a8b4 | (Elizabeth Mattijsen)++ | 5 files
Remove inlining tests
23:00
23:01 El_Che left
lizmat m: my @a = 10..20; @a[1,^Inf] = ^Inf; dd @a # sena_kun: please wait with a point release 23:27
camelia (timeout) 23:28
lizmat will look at that tomorrow
23:33 JRaspass joined