|
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
|
|||