[06:52] *** domidumont joined [07:35] good *, #moarvm [07:43] *** zakharyas joined [07:44] i'll concur about the '*' and the '#moarvm', but am reserving judgement on the 'good' [07:58] *** sena_kun joined [08:19] Yeah....I woke up a second time this night (once is sadly par for the course) and couldn't fall asleep again. Until I did and then dreamed that I couldn't fall asleep. [08:27] we could get into a four yorkshiremen contest here about waking up in the night (the baby is currently teething) [08:28] *** zakharyas1 joined [08:30] *** zakharyas left [08:31] in my time we got out of bed an hour before we went to sleep [08:32] you had a bed?! [08:34] *** zakharyas1 left [08:34] nine: https://github.com/MoarVM/MoarVM/pull/1451 is impressive. after it's merged i'll rebase https://github.com/MoarVM/MoarVM/pull/1438 and https://github.com/MoarVM/MoarVM/pull/1426 [09:19] MasterDuke: well it's your impressive work that prompted me to fix those things :) [09:22] thanks, but you don't want to see how these sausages are made... [09:22] one never does :D [09:57] ooo, this looks really cool https://comby.dev/blog/2021/03/26/comby-reducer [10:17] morning o/ [10:18] .oO( too late, last week it would have been still morning :-) [10:18] \o [10:18] m: my $a; my $s := now; $a := now for ^100_000; say now - $s; [10:18] rakudo-moar 726a75e24: OUTPUT: «0.9384962␤» [10:18] I wasn't intending to reply, but was more curious here - of this list, what *doesn't* Raku have? https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259531.html [10:18] W functions? [10:19] well, that's now only 0.19s locally (up from 0.03s before bug fixes), and there's only one failing spectest [10:19] Failed test 'Instant subtraction (non-integral seconds)' [10:19] expected: '0.285714' [10:19]      got: '0.285714285' [10:19] I feel that the the list is valid, but note also that half of those things need internals changes, or are impossible within any human timeframe [10:21] *** domidumont left [10:22] yeah, it's easy to make list of missing things [10:22] m: say (2/7).Num [10:22] rakudo-moar 726a75e24: OUTPUT: «0.2857142857142857␤» [10:23] my car misses a Mr. Fusion powersource [10:23] I think it's a *good* list, and I agree with most of it [10:23] I didn't mean at all to belittle it [10:23] I think it has most things that matter, and doesn't omit anything massive [10:23] I think we even do call the W functions in quite a few places in MoarVM [10:23] the test is https://github.com/Raku/roast/blob/master/S32-temporal/DateTime-Instant-Duration.t#L40 [10:24] it was more "a solution to most of these already exists" [10:24] Remind me what the /r flag is? [10:24] substition (or transliteration) returns the modified value. Original variable is unchanged [10:24] Oh, right :) [10:25] Yeah, we have that but differently done [10:26] A thing that's very true for Raku(do) also: "Simply put, we need more people, and we need to do better with the people we have. We need a way to get more people able to work on actual real core features, and we need to ensure that the people we do have can work on features as best as they can." [10:26] from the reply [10:27] Indeed. [10:28] I think much more than with those technical topics we can learn from Perl about these social aspects. [10:28] For example that we absolutely need to keep a good balance between backwards compatibility and the possibility for newcomers to be able to make contributions to the core. [10:29] Oops. I accidentally started a discussion. I didn't mean to distract people. [10:29] Personally I love Perl's backwards compatibility as a user and I've completely given up on getting any change into perl. [10:29] * nine is having lunch anyway :) [10:29] where did breakfast go? [10:30] that one with the IO module and the opcode hook was a real problem, in that different things expect different behaviours from the same "feature", and it was never thought through [10:31] In a slight deviation to my usual eating schedule I had a bit of cake with my coffee before the 11 o'clock meeting and I count that as breakfast ;) [10:31] aha, "safely in my tummy" [10:31] this being the phrase I was trying to encourage the children with, particularly when there are dogs around [10:32] on the basis of if it's not safely in *your* tummy, pretty soon it might be safely in a different tummy [10:42] https://github.com/rakudo/rakudo/pull/4265 now has the commit that speeds up `now`, but it still has the problem with that one spectest [10:43] MasterDuke: does it keep the old nqp::time_* ops working ? [10:43] yeah [10:43] Cool! [10:44] I would be in favour of merging all of that now [10:44] anybody any objections ? [10:44] I guess that one spec test failure counts as an objection? [10:45] well, time is one of those things i know is impossible to get right (like names and places), so i certainly would appreciate if people gave the diff a look [11:15] lizmat: i just made the minimal changes needed for Telemetry to work. it might be possible to simplify/optimize it to work in nanoseconds and reduce some of the math going on [11:16] MasterDuke: cool, will look at that after the merge [11:17] MasterDuke: look at the failing test, I believe we cannot fix that [11:17] since Instant no longer has a Rat at its source [11:18] and 2/7 cannot be represented correctly using integer / float representations [11:20] no merge if breakage [11:21] well, the test is just testing the string representation [11:22] MasterDuke: but you can't go from an approximation to a Rat, so that will never work? [11:23] true. but i wonder what master would say if the test is changed to is-deeply [11:24] fails with is-deeply [11:24] <2/7> [11:24] # got: Duration.new(<2/7>) [11:25] passes with: is-deeply diff(second => 2/7).Rat, 2/7 [11:25] ah, but the duration is carrying around the 2/7 [11:26] ah... did you change Duration as well to not have a Rat at its core ? [11:26] yeah [11:26] i'll see how easy it is to back that out [11:26] well... don't [11:27] and just change Instant instead [11:27] because I feel that using a Rat there is the wrong thing anyway [11:27] wait, don't what? [11:27] don't revert the Duration change [11:27] you won't be able to make a Rat out of a nanosecond (integer) value anyway [11:28] the whole intent of making Instant based on a Rat, was to give it more precision than floating point would [11:29] just nanoseconds / 1000000000 [11:29] hmmm... actually, that might work if you changed the .Rat methods on Instant and Duration ? [11:31] well, i do already [11:31] https://github.com/rakudo/rakudo/pull/4265/files#diff-823cb500d7cba754f1723b150d579257117c55bb9df5a57c24e938e5630e219eR30 [11:32] Cool [11:32] but that still makes the test fail then... what does it give for the values ? [11:33] # expected: '0.285714' [11:33] #      got: '0.285714285' [11:34] and with: is-deeply diff(second => 2/7).Rat, 2/7 ? [11:34] # expected: <2/7> [11:34] #      got: 0.285714285 [11:35] which seems odd [11:35] no, that's correct [11:35] because 2/7 can not really be represented as a string [11:35] so it chooses to do <2/7> instead [11:36] right [11:36] perhaps changing the test to: is diff(second => 2/7).Num, 2/7.Num [11:37] actually: is-deeply diff(second => 2/7).Num, 2/7.Num [11:37] this passes on master [11:38] hm, doesn't here [11:38] # expected: 0.2857142857142857e0 [11:38] #      got: 0.285714285e0 [11:40] https://github.com/rakudo/rakudo/pull/4265/files#diff-45927982f124bf65c3dfac4c83a9feea4d173b82733df1d67cb43fac2c88f2beR117-R119 [11:42] is-deeply diff(second => 2/7).Num, 2/7.Num, 'Instant subtraction (non-integral seconds)'; [11:42] doesn't pass for you on master ?? qeird [11:42] *weird [11:42] on my branch [11:44] aah... ok [11:46] would we have more freedom to change tests if we stick this change behind a lang version boundary? i.e., 6.e [11:47] how about: is diff(second => 2/7).fmt('%.9f'), (2/7).fmt('%.9f') [11:47] since the test *was* about string comparisons [11:50] *** lizmat_ joined [11:50] heh. fails in the last number (expected 6 got 5). `.fmt('%.8f')` works... [11:51] well, that'd be close enough, I'd say [11:53] it also passes if you just change the `is` to `is-approx` [11:53] *** lizmat left [11:56] *** lizmat_ is now known as lizmat [11:56] MasterDuke: https://github.com/Raku/roast/commit/b97859e3f385efae89861d14818f4e140944feb1 [11:58] cool. that'll have to be cherry-picked back to the errata branches, right? [12:01] yeah, guess so :-) [12:02] yes [12:02] I'll do cherry-picking anyway, but doing so now will save some time when releasing. [12:02] Also, can anyone please check kill.t test on errata branches? [12:11] sena_kun: I get the same errors as you [12:15] sena_kun: oh, actually... did you run make stresstest after switching branches, or just runn kill.t manually? Because that failing test should be fudged [12:16] nine, on errata branches this test dies for me when I do make stresstest, yes. [12:16] Actually, I do `z ss` using zscipt, but I believes it does the same. [12:17] And if you run kill.rakudo.moar manually? [12:17] s/es/e/ [12:17] nine, https://gist.github.com/Altai-man/8c87b45ad885409e627b3216537f7aa8 <- ? [12:19] That does say that it's TODOed: not ok 9 - did we get STDOUT # TODO [12:19] Though what's TODO is less fixing rakudo and more fixing the test, which I did a year ago in roast master [12:19] nine, but you can re-create failure when running stresstest, no? [12:20] sure [12:22] Phew. So yes, 1)when running separately it seems to be ok; 2)when running as part of the suite it complains about number of tests not matching. [12:22] Well, actually no [12:23] Hm? [12:24] Sorry, I misspoke. make stresstest passes on 6.c-errata and 6.d-errata [12:31] i just had a fail in t/spec/MISC/bug-coverage-stress-6.d.t [12:37] MasterDuke: that one's still waiting for https://github.com/rakudo/rakudo/pull/4253 [12:37] ah, thought that had already been merged, nm then [12:38] I think I'll just change the fix to $l.lock; $.unlock; and leave the potential optimization for later [12:39] otherwise passing tests all around for the nqp::time PRs [12:41] hm, but maybe there's a way to get back some of the performance of `now` i initially had... [12:55] *** zakharyas joined [13:04] initial idea didn't work...i got rid of one division, but added enough multiplications to more than compensate [13:11] *** lucasb joined [13:12] nine, cannot reproduce it now, so just a noise, I guess. [13:22] ok, by making some (i believe reasonable) assumptions and hardcoding some values, got `my $a; my $s := now; $a := now for ^100_000; say now - $s;` back down to 0.045s [13:29] i.e., the Instant we create with `now`is always after the complete list of leap seconds, so no need to calculate that for each call [14:07] and now down to 0.03s [14:08] extrapolating wildly, it will be free in about 3 hours from now, and if you keep going further then it will start to return the answer before you even called it :-) [14:09] cool - 0.03s sounds awesome [14:11] it's fun to compare a before and after profile. something like 3.8m fewer things allocated [15:44] *** sena_kun left [15:44] *** sena_kun joined [15:46] *** lucasb left [15:48] *** lucasb joined [17:08] *** patrickb joined [17:26] *** patrickb left [18:00] *** patrickb joined [18:22] *** zakharyas left [19:05] *** sxmx left [19:09] for some reason I got pinged on Twitter about this: https://www.i-programmer.info/news/90-tools/14454-regexploit-put-a-stop-to-regular-expression-dos-attacks.html [19:30] *** zakharyas joined [20:06] *** patrickb left [20:42] *** zakharyas left [20:48] does anyone know (if there is) an easy way to generated different code for the JVM backend in a module? something similar to the preprocessor directives (#?if jvm ... #endif) we have for the core. More specifically I'd like to special case two declarations for the JVM in lib/NativeCall.rakumod -- see https://github.com/rakudo/rakudo/issues/3043#issuecomment-809679990 [20:52] $*VM [20:53] r: say $*VM.name eq 'jvm' [20:53] rakudo-jvm 08b449e1a: OUTPUT: «True␤» [20:53] ..rakudo-moar 726a75e24: OUTPUT: «False␤» [20:55] r: if $*VM.name eq "jvm" { my $foo = "jvm" } else { my constant $foo = "moar" }; say $foo [20:55] rakudo-moar 726a75e24: OUTPUT: «5===SORRY!5=== Error while compiling ␤Variable '$foo' is not declared␤at :1␤------> 3else { my constant $foo = "moar" }; say 7⏏5$foo␤» [20:55] ..rakudo-jvm 08b449e1a: OUTPUT: «5===SORRY!5=== Error while compiling ␤Variable '$foo' is not declared␤at :1␤------> 3else { my constant $foo = "moar" }; say 7⏏5$foo␤» [20:55] that's what I'd like to do ... [20:59] r: BEGIN q:c{my {'constant' if $*VM.name eq 'moar'} $foo = "{$*VM.name}";}.EVAL; say $foo; [20:59] rakudo-jvm 08b449e1a: OUTPUT: «5===SORRY!5=== Error while compiling ␤An exception occurred while evaluating a BEGIN␤at :1␤Exception details:␤ 5===SORRY!5=== Error while compiling /home/camelia/EVAL_0␤ Malformed my␤ at /home/camelia/EVAL_0:1␤ -----…» [20:59] ..rakudo-moar 726a75e24: OUTPUT: «5===SORRY!5=== Error while compiling ␤An exception occurred while evaluating a BEGIN␤at :1␤Exception details:␤ 5===SORRY!5=== Error while compiling /home/camelia/EVAL_0␤ Malformed my␤ at /home/camelia/EVAL_0:1␤ ----…» [21:02] hmm EVAL. I didn't consider that. But it's probably not the right thing to do ;) [21:03] maybe it would be 'good enough' to just drop the constant on MoarVM. [21:05] bartolin_: I talked with camelia for a bit. There's another problem that I forgot: EVAL is a lexical context; $foo won't leak. [21:05] oh, so it wouldn't even help. japhb++ [21:06] Come to think of it, it's probably a CompUnit. [21:11] notable6: weekly reset [21:11] lizmat, Moved existing notes to “weekly_2021-03-29T21:11:03Z” [21:20] and another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2021/03/29/2021-13-games-pop/ [21:34] *** sxmx joined [21:36] anyone have an idea why https://github.com/MasterDuke17/Text-Diff-Sift4/blob/speed_up_pure_raku_version/lib/Text/Diff/Sift4.pm6 would generate massive profiles? just running the sift4 sub with a fixed string against 1000 words from a scrabble list generates a 67mb html profile and the file size blows up fast [22:07] *** sena_kun left [22:23] *** Voldenet left [22:28] *** Voldenet joined [22:28] *** Voldenet left [22:28] *** Voldenet joined [23:25] *** Voldenet left [23:30] *** Voldenet joined [23:30] *** Voldenet left [23:30] *** Voldenet joined