[02:15] *** MasterDuke left [02:47] *** kvw_5_ joined [02:50] *** kvw_5 left [03:20] *** leont left [04:20] *** linkable6 left [04:20] *** evalable6 left [04:21] *** evalable6 joined [04:22] *** linkable6 joined [04:28] *** sortiz joined [04:46] lizmat: Now that Map.iterator is multi, wouldn't it be a good idea to short-circuit Map.pairs? [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 [09:07] 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] 2021-02-21T23:08:37Z #raku nine MasterDuke suggested I ask you https://colabti.org/irclogger/irclogger_log/raku?date=2021-02-21#l329 [09:08] Got that by adding a "or diag $SIL.report" after the test [09:09] that 11-inline-hash-key.t is certainly the winner in failed tests, I see it regularly [09:11] (I have been updating the flapper metaticket, I hope no one objects) [09:18] *** sena_kun left [09:27] *** sena_kun joined [09:42] nine++ [09:43] nine: are there other prefixes than "unspecialized" that can be used there ? [09:46] I don't know. I didn't know we had an inline log until I saw it used in MoarVM::SIL :) [09:49] 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 [09:50] Looks like "unspecialized " is the only one: https://github.com/MoarVM/MoarVM/blob/master/src/spesh/optimize.c#L21 [09:52] ¦ rakudo: f860950410 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod [09:52] ¦ rakudo: Add BB.specialized attribute, fix name checking [09:52] ¦ rakudo: [09:52] ¦ rakudo: Apparently a BB can be inlined *without* it being specializd, and [09:52] ¦ rakudo: that is reported in the log. Unfortunately, this wasn't taken into [09:52] ¦ rakudo: account when looking for names, so name checks (like the [09:52] ¦ rakudo: t/09-moar/*inline*.t tests) would report failure, when in fact the [09:52] ¦ rakudo: name checked for *was* inlined, but without being specialized. [09:52] ¦ rakudo: [09:52] ¦ rakudo: nine++ for tracking the source of these flappers [09:52] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/f860950410 [10:11] 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:13] yeah, I just realized there's an off-buy-one error in the code [10:14] *by [10:16] buy one, get none free [10:20] ¦ rakudo: b0f7ce4ed4 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod [10:20] ¦ rakudo: Make "unspecialized" test more robust [10:20] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/b0f7ce4ed4 [10:26] lizmat: typo: unspeciaized [10:26] also white space on the line before [10:28] argh... must not be awake enough yet [10:29] ¦ rakudo: aed69bb222 | (Elizabeth Mattijsen)++ | lib/MoarVM/SIL.rakumod [10:29] ¦ rakudo: Properly spell specialized *sigh* [10:29] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/aed69bb222 [10:33] *** MasterDuke left [10:34] *** MasterDuke joined [10:35] huh, still getting that t/09-moar/14-inline-comparators-str.t fail at HEAD [10:40] MasterDuke: could you gist the report when there's a fail ? [10:41] same here [10:41] that's how I noticed the typo [10:41] thing is, I can't get it to fail on my machine [10:42] it's hard to write tests for cases that you can't get to fail personally :-( [10:42] https://gist.github.com/MasterDuke17/d74f0b761f6757d87ee2c85e0e2d83f2 [10:43] 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 [10:43] yeah, i'm at 2021.02-9-gaed69bb22 [10:44] sorry for this Monday morning mess... [10:44] something more serious that broke in 2021.02 [10:44] m: (1..10)[1,^Inf] [10:45] rakudo-moar 3235f3e42: OUTPUT: «(timeout)» [10:45] and probably broken by me [10:45] I will look into this after the RWN [10:50] committable6: 2020.12 (1..10)[1,^Inf] [10:50] MasterDuke, ¦2020.12: «» [10:51] * AlexDaniel` hugs Altai-man_ [10:52] any reason not to bisect it, by the way? [10:52] bisect: old=2020.12 (1..10)[1,^Inf] [10:52] AlexDaniel`, Bisecting by exit signal (old=2020.12 new=aed69bb). Old exit signal: 0 (None) [10:53] AlexDaniel`, bisect log: https://gist.github.com/3968a742df81518e7442163c22331cce [10:53] AlexDaniel`, (2021-01-08) https://github.com/rakudo/rakudo/commit/ca7bc91e71afe9373b57cd629215f843e8026df1 [10:53] MasterDuke: I know where the problem is, just not how to easily fix it [10:54] m: dd (1..10)[lazy 1,^Inf] [10:54] rakudo-moar 3235f3e42: OUTPUT: «(2, (1, 2, 3, 4, 5, 6, 7, 8, 9, 10))␤» [10:54] m: dd (1..10)[1,^Inf] [10:54] huh [10:54] rakudo-moar 3235f3e42: OUTPUT: «(timeout)» [10:54] as soon as a lazy list is found, it should switch to lazy semantics, which means: stop when the source has run out [10:55] by making the outer list of indexes lazy, it will apply lazy semantics and do the right thing [10:56] *** [Tux] left [10:59] *** linkable6 left [10:59] *** [Tux] joined [11:00] *** linkable6 joined [11:01] R#4216 [11:01] *** linkable6 left [11:01] wut [11:02] very strange [11:04] *** linkable6 joined [12:29] *** JRaspass joined [12:31] ¦ rakudo: lizmat self-assigned Test t/78_fragment.t in Tux CSV module hangs https://github.com/rakudo/rakudo/issues/4216 [13:35] lizmat: still seeing a Failed test 'Was infix: inlined?' when building a package. This time it really doesn't seem to get inlined and got refused instead: [13:35] [ 101s] # 3x infix: BB(4786, 234 bytes) -> abs2rel BB(12041): [13:35] [ 101s] # target has a :noinline instruction - ins: speshresolve [13:35] that's what i get also [13:40] When it does succeed, it's: 2x infix: BB(4786, 68 bytes) -> abs2rel BB(12041) [13:41] But wait...that doesn't have anything to do with the test code! [13:41] ¦ rakudo: 655f1ac2af | (Elizabeth Mattijsen)++ | 3 files [13:41] ¦ rakudo: Give each inline test its own scope to inline to [13:41] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/655f1ac2af [13:41] yeah, was wondering why abs2rel was involved there [13:41] perhaps that fixes that ?? ^^ [13:41] The actual test code would look like this: infix: BB(4788, 68 bytes) -> BB(3) [13:42] lizmat: have you checked the output? [13:43] infix: BB(4784, 174 bytes) -> BB(9) [13:43] infix: BB(4786, 68 bytes) -> BB(3) [13:43] infix: BB(4788, 68 bytes) -> BB(4) [13:43] infix: BB(4790, 68 bytes) -> BB(7) [13:43] infix: BB(4792, 68 bytes) -> BB(8) [13:43] infix: BB(4794, 68 bytes) -> BB(5) [13:43] infix: BB(4796, 68 bytes) -> BB(6) [13:43] after the latest change [13:43] # 2x infix: BB(4786, 68 bytes) -> abs2rel BB(12041) [13:43] # infix: BB(4788, 68 bytes) -> BB(4) [13:43] # infix: BB(4790, 68 bytes) -> BB(7) [13:43] # infix: BB(4792, 68 bytes) -> BB(8) [13:43] # infix: BB(4794, 68 bytes) -> BB(5) [13:43] # infix: BB(4796, 68 bytes) -> BB(6) [13:43] I think the BB numbers check out actually now [13:46] hmmm... perhaps I should make each op test in a separate sub and have it check the name of the BB inlined into? [13:48] *** cog__ left [13:51] That wouldn't fix that infix: just doesn't get inlined in this case [13:51] But it would make the test more robust and prevent false negatives [13:53] linner& [14:09] *** cog joined [14:12] ¦ rakudo: MasterDuke17++ created pull request #4217: Fix memory leak in runner [14:12] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/4217 [14:30] notable6: weekly [14:30] lizmat, 1 note: 2021-02-21T14:08:51Z : https://twitter.com/koto_san_kana/status/1363490820431765507 [14:30] notable6: weekly reset [14:30] lizmat, Moved existing notes to “weekly_2021-02-22T14:30:25Z” [14:50] ¦ rakudo: 18735ae9a8 | (Daniel Green)++ | src/vm/moar/runner/main.c [14:50] ¦ rakudo: Fix memory leak in runner [14:50] ¦ rakudo: [14:50] ¦ rakudo: If the `(PERL6|RAKUDO)_HOME` env var is set, `rakudo_home` is [14:50] ¦ rakudo: malloced, but wasn't being freed. [14:50] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/18735ae9a8 [14:50] ¦ rakudo: d58402c7c0 | MasterDuke17++ (committed using GitHub Web editor) | src/vm/moar/runner/main.c [14:50] ¦ rakudo: Merge pull request #4217 from MasterDuke17/fix_memory_leak_in_runner [14:50] ¦ rakudo: [14:50] ¦ rakudo: Fix memory leak in runner [14:50] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/d58402c7c0 [14:57] *** JRaspass left [15:12] awww... /me has to remove an entry from the RWN :-) [15:18] heh, i suspect there will still be enough content [15:25] *** maggotbrain left [15:37] and another Rakudo Weekly hits the Net: https://rakudoweekly.blog/2021/02/22/2021-08-first-21/ [15:43] *** maggotbrain joined [15:50] lizmat: BTW, they seemingly heard your complains. I saw in the news that the latest Safari is gaining support for webm. :) [15:54] MasterDuke: it still fails. [16:00] yeah, i was just looking at a corefile from coredumpctl. it pointed to https://github.com/MoarVM/MoarVM/blob/master/src/spesh/worker.c#L24 which is annoying because i doesn't point out the line inside the macro [16:37] *** MasterDuke left [16:48] MasterDuke that --full-cleanup segfault looks familiar [16:53] *** donaldh joined [16:57] *** JRaspass joined [17:04] codesections: that re-checking of dependencies you mentioned in https://stackoverflow.com/questions/66210606/why-do-different-ways-of-calling-raku-result-in-very-different-startup-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:16] *** donaldh left [17:23] nine++ [17:23] s/ // [17:45] *** domidumont left [17:51] *** domidumont joined [18:01] *** domidumont left [18:08] 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 [18:08] bisectable6: dd (1..10)[lazy 1,(8..12)] [18:08] lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight [18:08] lizmat, Output on all releases: https://gist.github.com/283df1d7053c84ac30e52ff7ccdb1544 [18:08] lizmat, Bisecting by output (old=2020.12 new=2021.02) because on both starting points the exit code is 0 [18:09] lizmat, bisect log: https://gist.github.com/83a91a97f13ba54eab7dae60ae062b02 [18:09] lizmat, (2021-01-08) https://github.com/rakudo/rakudo/commit/ca7bc91e71afe9373b57cd629215f843e8026df1 [18:09] lizmat, Output on all releases and bisected commits: https://gist.github.com/5a099f66448ab54f4243838e8f14a44f [18:09] yeah, what I feared: the old version was buggy as well [18:09] m: dd (1..10)[lazy 1,(8..12)] [18:09] rakudo-moar 3235f3e42: OUTPUT: «(2, (9, 10))␤» [18:10] Now, I would have expected that the lazy semantics would *not* carry over into the non-lazy sublist [18:12] m: dd (1..10)[1,(8..12),3] [18:12] rakudo-moar 3235f3e42: OUTPUT: «(2, (9, 10, Nil, Nil, Nil), 4)␤» [18:18] 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:36] *** Xliff joined [18:36] \o [18:36] hey Xliff, you have a message: https://gist.github.com/21453045be32ce55dd61ad7fafae7828 [18:37] ,tell patrickb Ah, piffle! Thanks for the update. [18:38] Since there doesn't seem to be a #comma channel, can someone tell me how to set the Raku SDK in comma? [18:43] 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 [18:43] Usually its `bin` directory of where your installation lives. [19:12] sena_kun++ # Thanks! [19:12] yw [19:48] *** MasterDuke joined [19:50] *** JRaspass left [20:08] ¦ rakudo: 5eeddd37fa | (Elizabeth Mattijsen)++ | 4 files [20:08] ¦ rakudo: Fix for #4216 [20:08] ¦ rakudo: [20:08] ¦ rakudo: It turned out that a lazy iterable as part of a non lazy list of indexes [20:08] ¦ rakudo: in a slice, had the possibility of hanging because eager semantics where [20:08] ¦ rakudo: being used on the lazy iterator, e.g. in `(1..10)[1,^Inf]` [20:08] ¦ rakudo: [20:08] ¦ rakudo: This commit removes all of the Array::Slice classes that existed for [20:08] ¦ rakudo: <…commit message has 20 more lines…> [20:08] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/5eeddd37fa [20:08] *** linkable6 left [20:08] this also unbreaks Text::CSV [20:09] *** linkable6 joined [20:12] ¦ roast: 187d894660 | (Elizabeth Mattijsen)++ | S09-subscript/slice.t [20:12] ¦ roast: Mark failing test as todo for now [20:12] ¦ roast: [20:12] ¦ roast: The semantics of a lazy list slipped into indexes of an array slice, [20:12] ¦ roast: appear to be assuming that the laziness of the Slip would actually [20:12] ¦ roast: influence the laziness of the outer sequence. I don't believe this [20:12] ¦ roast: to be sane semantics. [20:12] ¦ roast: [20:12] ¦ roast: See: https://github.com/rakudo/rakudo/commit/5eeddd37fa [20:12] ¦ roast: review: https://github.com/Raku/roast/commit/187d894660 [20:13] sena_kun: not sure this warrants a point release, but if you want, you can :-) [20:39] broken new feature: no dot release, newly broken existing feature: a dot release could unbreak real life code [20:48] 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:50] nice. isn't that the optimization i recently un-disabled? [20:56] ¦ nqp: MasterDuke17++ created pull request #696: Support some missing Rakudo command line flags [20:56] ¦ nqp: review: https://github.com/Raku/nqp/pull/696 [21:22] sigh, I cannot easily cherry-pick the commit to the release branch. [21:22] deleted by us: src/core.c/Array/Slice.pm6 [21:22] deleted by us: src/core.c/Rakudo/Internals/PostcircumfixAdverbs.pm6 [21:22] both modified: src/core.c/array_slice.pm6 [21:22] deleted by us: tools/build/makeARRAY_SLICE_ACCESS.raku [21:24] Oh no, appveyor is failing all the time cause of the inlining tests. [23:00] ¦ rakudo: a5ca53a8b4 | (Elizabeth Mattijsen)++ | 5 files [23:00] ¦ rakudo: Remove inlining tests [23:00] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/a5ca53a8b4 [23:01] *** El_Che left [23:27] m: my @a = 10..20; @a[1,^Inf] = ^Inf; dd @a # sena_kun: please wait with a point release [23:28] rakudo-moar 3235f3e42: OUTPUT: «(timeout)» [23:28] will look at that tomorrow [23:33] *** JRaspass joined