00:49 evalable6 left, linkable6 left 00:51 evalable6 joined, linkable6 joined 01:05 cog joined 01:13 kvw_5 joined 01:16 japhb joined 01:58 MasterDuke left 02:02 Voldenet joined, Voldenet left, Voldenet joined 04:38 Xliff left 05:37 frost-lab joined 06:07 domidumont joined 06:10 Xliff joined
releasable6 Next release in ≈2 days and ≈11 hours. 2 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
07:00 MasterDuke joined
nwc10 what triggered that? Does releasable6 auto-announce at particular times? 07:00
AlexDaniel` Yes 07:01
Somewhat randomly, too
nwc10 ah OK. That was 59 hours, which is an odd number (er, OK, literally, and I think prime too)
MasterDuke m: say 59.is-prime 07:27
camelia True
tellable6 2021-04-14T20:25:23Z #moarvm <jnthn> MasterDuke: I'm not sure why the presence of something with a `where` that is never used would make a difference even on master, and I can't see anything in the new-disp approach that would lead to that.
08:10 softmoth left
MasterDuke i just tried again moving the Failure.new()s out of infix:<**> and into a separate sub. but it results in the bytecode of infix:<**> increasing? and why do the facts and spesh slots have references to Failure and X::Numeric::Underflow when it doesn't say that the separate sub is getting inlined in to infix:<**> (it's never called in the example i'm 09:09
trying with)?
09:10 Kaeipi joined
MasterDuke lizmat: have you seen ^^^ sort of behavior before? 09:11
lizmat nope 09:32
MasterDuke lizmat: huh. do you mind seeing if the same thing happens for you? i don't think you need my branch, pretty sure i saw the same thing just making that change alone on master 09:40
lizmat the odd thing is, that I never saw any infix:<**> related activity in the spesh inline log at all 09:41
what is the test code that you use ?
MasterDuke and complete change of topic, but the "Core Developments" section of rakudoweekly.blog/2021/04/13/2021-...irst-conf/ (and the older ones too) the first entry is formatted differently, it has an `style="color:initial;"` in the <em> and <span> 09:42
lizmat huh? 09:43
lizmat checks
MasterDuke m: my $a; $a := $_ ** 2 for ^10_000_000; say now - INIT now # code i was testing with
camelia 7.219981958
lizmat weird, it doesn't in the editor 09:44
MasterDuke i see 'identity' inlined *into* infix:<**>, but that's it
lizmat yup, but nothing with infix:<**> itself
MasterDuke the bytecode is way to big regardless, but jnthn was explaining why it might not even get to the code that checks that 09:45
lizmat so what is causing this bloat ? 09:46
or are you saying the static optimizer doesn't unbloat ?
MasterDuke i'm not sure, but i don't think it's the static optimizer's fault. colabti.org/irclogger/irclogger_lo...-04-13#l52 i'm not quite following the answer, but i think he's saying that case 2 is failing, i.e., spesh can't prove the code object it's calling is constant. but why not i have no idea 09:51
lizmat MasterDuke: how do you figure out what the bytecode size is if it doesn't show up in the spesh inline log? 10:01
nine MasterDuke: where's that patch again for infix:<**>? 10:02
MasterDuke it's in a regular spesh log. at the end of the 'after'
After: Spesh of 'infix:<**>' (cuid: 3543, file: SETTING::src/core.c/Int.pm6:369) 10:03
nine: github.com/MoarVM/MoarVM/pull/1470 and github.com/rakudo/rakudo/pull/4320
nine I thought I'd seen a gist or so where you moved the error handling into its own sub and was surprised that this increased the byte code size 10:08
10:08 MasterDuke left 10:09 MasterDuke joined
MasterDuke gist.github.com/MasterDuke17/95314...04fef337c3 10:09
nine MasterDuke: according to my spesh logs the patch reduces the frame size from 978 to 938 bytes and the bytecode size from 4685 to 4471 bytes 10:12
MasterDuke huh. i was just testing a couple min ago and it got bigger. do you also see references to Failure and X::Numeric::... in the facts? 10:17
nine Only in the unpatched version
Maybe just a confusion of spesh log files? I know I've got enough of those lying around to get confused 10:18
MasterDuke maybe. i was trying to be careful, but yeah, there are a bunch here... 10:19
nine: did you follow jnthn's explanation of why infix:<**> is entering that case that doesn't write an entry to the inline logs? 10:20
ugh, i guess it was just confusion over which log i was looking at (though i must have made the same mistake several times?). now i'm getting `Frame size: 656 bytes (20 from inlined frames)` and `Bytecode size: 2884 byte` before and `Frame size: 602 bytes (20 from inlined frames)` and `Bytecode size: 2497 byte` after 10:27
nine I did 10:30
MasterDuke somehow the code object for infix:<**> is non constant? 10:33
moritz_ what do you mean by that? 11:22
11:22 moritz_ is now known as moritz
MasterDuke if i change moarvm to do the negation when given a negative exponent, and then rework infix:<**> to only check concreteness once (but does require two nqp::isge_I($b, 0) again), and have the failure in a separate sub, timings stay pretty much the same, but frame and bytecode are reduced: `Frame size: 504 bytes (20 from inlined frames)` and 11:23
`Bytecode size: 2191 byte`
nine MasterDuke: gdb tells the story
MasterDuke oh?
nine MasterDuke: according to the spesh log we do know the value for r3(3) (which holds infix:<**>), so why don't we find that static frame when trying to inline the call?
The answer is that we learn about r3(3)'s known value only in the post-inlining run 11:24
In post_inline_visit_bb we copy the facts.
So the question morphs from "why don't we inline" to "why don't we know beforehand the value of decont(getlexstatic_o('infix:<**>')) 11:25
MasterDuke nice analysis 11:27
i don't have answer to the new question
nine But I may have. 11:29
lizmat wonders if this is something special abouy infix:<**> or for any infix:<> ? 11:30
nine lizmat: it isn't
lizmat wonders what it is then :-) 11:35
nine This is the spesh graph at the time we're trying to inline: gist.github.com/niner/90d542bc9ba9...c93ae94f37 11:39
In line 33 you see that we already replaced the getlexstatic_o with an sp_getspeshslot and in line 34 that we've already replaced the decont with set r3(5), r3(2). 11:41
If you look at the facts for that new set op, we have flags=11 KnTyp KnVal Concr (type: Sub+{is-pure}+{Precedence} mixin), but not a known value!
lizmat so it's a case of premature optimization ? 11:44
nine Not really that either. It looks more like we don't propagate the knowledge we have agressively enough. The knowledge about the value of the decont result does make it into the facts eventually, but in this case too late for optimizing the call 11:58
MasterDuke we need to sprinkle more copy_facts() calls around? 12:32
nine could be 12:39
MasterDuke any idea where? 12:40
nine not yet 12:43
13:27 frost-lab left
sena_kun vrurg, ping? Can we get a Blin run please? 14:48
MasterDuke fyi, the problem with Games::TauStation::DateTime is still unfixed. not sure what the right move is 14:52
sena_kun MasterDuke, what's the ticket? 14:53
vrurg sena_kun: sure.
sena_kun: have you merged the branch? Can I run it on master?
MasterDuke there isn't one. github.com/rakudo/rakudo/pull/4311 is related 14:54
sena_kun vrurg, sadly I did not. I want to write support for proper dependency resolution, but for that I have to play with blin locally and for that I need a good machine and for that... well, sometime in future. :S
vrurg, tl;dr a branch. 14:55
vrurg Ok, will run it on the branch again. np.
sena_kun: BTW, do you know if it's ok to unset DISPLAY to mute the X-popping apps? 14:56
sena_kun vrurg, feel free to.
MasterDuke, sigh, that's a difficult situation we're in. :S TauStation does not look to me like a tiny module we can just fix and go on, I wonder why it relies on .raku format though. 14:58
Ah, silly me, it's just a module and it's a community one too. 14:59
MasterDuke, if we can write a patch before release to the module itself, no need to do a bend in rakudo, I think. 15:00
[Tux] Rakudo v2021.03-175-gad81b9806 (v6.d) on MoarVM 2021.03-49-gd11bd7f11
csv-ip5xs0.878 - 0.911
csv-ip5xs-209.500 - 9.687
csv-parser26.031 - 26.665
csv-test-xs-200.376 - 0.393
test7.974 - 8.172
test-t2.388 - 2.412
test-t --race0.975 - 0.988
test-t-2042.146 - 44.361
test-t-20 --race11.544 - 11.771
 15:06
vrurg sena_kun: is output/ is where blin keeps its state between runs? I currently wipe out ./output, ./installed, and ./data before each run, but should probable left output intact. 15:13
sena_kun vrurg, yes, output/ 15:14
vrurg oki, thanks!
17:11 Kaeipi left 17:22 domidumont left 17:26 Kaiepi joined
vrurg sena_kun, MasterDuke – gist.github.com/vrurg/909802df8b6f...e1a42129a9 17:27
sena_kun vrurg, thanks! 17:28
hmm, Test::Deeply::Relaxed seems very curious, I am sure we had issues with it before.
oh 17:29
So it was reported at github.com/rakudo/rakudo/issues/4199 17:30
The offending commit is github.com/rakudo/rakudo/commit/9e...6e1d2b26fc
Then lizmat++ reverted it in github.com/rakudo/rakudo/commit/9e...6e1d2b26fc
But 11 days ago github.com/rakudo/rakudo/commit/df...075fb160eb <- the same thing was restored it seems. 17:31
"Hopefully we'll have some more time before the 2021.04 release to
figure out the cause of any ecosystem breakage."
lizmat, just fyi ^
lizmat yeah, I'll look at Test::Deeply::Relaxed again
sena_kun lizmat++
18:47 lucasb joined
Geth nqp: ff157915ca | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for the decont logging revert
 19:20
rakudo: 6fdc2b6907 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump MoarVM for decont logging

Confirmed this also reverts the slowdown in Text::CSV's test-t canary.		 19:32
tbrowder .ask lizmat what do you think of a negative epoch value for DateTime being a signal that the value being input is a julian date? 19:49
tellable6 tbrowder, I'll pass your message to lizmat
lizmat tbrowder: how would that further affect a DateTime object ? 19:50
tbrowder the disconnect i'm finding is between days and seconds between the unix epoch handling and translation to julian dates internally. i can get to within 12 hrs with my current effort, and thatbis tantalizingy close, but inputting jd as a negative epoch should work exactly. 19:54
i'm probably missing some constant somewhere, but haven't found it yet. 19:55
lizmat any idea what causes that 12 hour discrepancy? Or is that your question ?
tbrowder no idea yet, but jd are integer days plus a day fraction, so i may be doing something wrong. 19:56
MasterDuke m: say DateTime.new(-234234) # but wouldn't that change this? 19:57
camelia 1969-12-29T06:56:06Z
tbrowder hm, but i'm not sure the answer is correct if it's before the unix epoch 19:59
19:59 MasterDuke left, MasterDuke joined
lizmat m: say DateTime.new(-1) 19:59
camelia 1969-12-31T23:59:59Z
lizmat looks ok for the first second before epoch 20:00
tbrowder yeah, but i'm trying to reach back to -4000 20:01
MasterDuke -4000 seconds? 20:03
tbrowder i was looking at maybe adding another attribute to role Dateish to show days since WAY back to the Julian day zero.
no fractions, just a total daycount
not to be confused with daycount as exists now 20:04
4000 years 20:05
back to -4712/1/1.5 20:06
got to go...back later
MasterDuke m: say DateTime.new(0).earlier(:4000years).posix
camelia -126227808000
vrurg sena_kun: do you need another run? 20:32
sena_kun vrurg, apparently.
vrurg Ok
tbrowder m: say DateTime.new(:year(-4172), :month(1), :day(1), :hour(12)).posix 21:07
camelia -193822804800
tbrowder which is julian-date 0.0 21:08
m: my $s = 193822804800; my $d = $s/86400; say $d 21:10
camelia 2243319.5
tbrowder the devil is in the details--still experimenting, 21:11
lizmat m: my @a = now xx 10; dd @a 21:34
camelia Array @a = [Instant.from-posix(1618522461.33540563), Instant.from-posix(1618522461.335706478), Instant.from-posix(1618522461.335709183), Instant.from-posix(1618522461.335711637), Instant.from-posix(1618522461.335714113), Instant.from-posix(1618522461.…
lizmat now, if you run that on Windows on 2021.03, you get 10 identical Instants
(probably the same instant)
moon-child or maybe the windows clock is less precise? 21:35
lizmat possibly
hmmm
moon-child (does windows have a vdso? If not then it wouldn't make sense, but I think part of the point of ntdll is to do vdso stuff) 21:36
tbrowder lizmat are you completely against another DateTime attribute?
lizmat tbrowder: if it is just for Julian Dates, it would take very strong convincing 21:37
tbrowder ok
just an integer? 21:38
an unsigned int
lizmat it's not about the type, it's about increasing the size of an object that won't be used by the majority of uses 21:39
tbrowder gotcha
lizmat tha attrribute I mean
tbrowder yep 21:40
lizmat hmmm... after the latest bump, I'm getting Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' 22:07
e.g. when trying to install OO::Monitors with zef 22:08
going to sleep on that &
japhb Full rebuild after bump WFM. 22:22
22:24 Geth left
tbrowder lizmat: good news i think the existing DateTime does do the right thing without any changes. but the documentation needs updating to explain it a bit better. 23:09
i have some good test data that shows the JPL time conversion is correct and i found one of my comparison tests had a typo. 23:10
i will add some tests to roast to tidy it all up. DT is very cool...good work! 23:11
vrurg .tell sena_kun I've updated the same gist at gist.github.com/vrurg/909802df8b6f...e1a42129a9 23:25
tellable6 vrurg, I'll pass your message to sena_kun
23:40 b2gills 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!