github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:33
is it possible to take a heap snapshot of a long running program?
I can cope with an answer of Yes, even if Yes is "hook gdb up to the running process and then use it to call this C function"
nwc10 I can't find this in the docs. 07:34
nine nwc10: I think you'd need to run it with --profile-kind=heap from the start 07:37
nwc10 I'd rather not do that - at least not to the production code, as it needs to keep runnig 07:38
nine I know the feeling :)
nwc10 it's run out of systemd, and it does stuff the entire office notices 07:39
oh, and also people would ask why I wasn't working on $other, which the ticketing system thinks that I'm working on
Altai-man_ We are all set to do a MoarVM release. It would be truly awesome to do it either today or tomorrow (I'll prepare release branch today and will produce a build ASAP as MoarVM release will be available). 09:05
jnthn nwc10: I thought that Telemetry could be used to a heap snapshot on demend? 10:48
timotimo implemented that, I think
nwc10 jnthn: from my reading of the code, it looked like it 10:49
and lizmat answered usefully on #rako
but distracted by "real" $ork
or, at least, the thing the ticketing system thinks that I'm working on 10:50
(and something else it also doesn't need to know about)
lizmat aaah... yes... now I remember... :-) 11:01
timotimo sneaked that in... :-)
now *that* indeed lacks documentation
nine preparing ChangeLog 11:07
sena_kun nine++ 11:10
Geth MoarVM: 80ba23a7d1 | (Stefan Seifert)++ | docs/ChangeLog
Update ChangeLog for 2020.02 release
 11:15
nine Steps 1-3 of the release guide complete (via tools/release). 11:35
Actually steps 1-4 with the above commit 11:36
Guest1277 releasable: next 12:11
releasable6 Guest1277, Next release in ≈1 day and ≈6 hours. There are no known blockers. 163 out of 250 commits logged
Guest1277, Details: gist.github.com/ef518eaeb5fb419746...2a327a4186
Guest1277 no blockers, hmm
Altai-man_ Guest1277, hmm? 12:13
Guest1277, the blockers were resolved and we're releasing on schedule, is there any news preventing it? 12:14
Guest1277 Altai-man_: no :) but new blockers have a tendency to show up when you least expect them 12:17
timotimo i've been meaning to make debugserver able to take a heap snapshot 12:49
then you won't have to change the code
jnthn +1 12:50
timotimo it'll most likely just write to a local file rather than transmit it over the socket, though 12:51
Geth MoarVM: 926349cde6 | (Stefan Seifert)++ | tools/release
Add logging commits to ChangeLog and bumping VERSION to tools/release

Rewrote the script in raku to make it more maintainable and extensible. It now understands the --/update-changelog --/update-version and
  --/check-git-status options.
It also now uses the machine's CPU count as default for make jobs and TEST_JOBS.		 13:37
nine Obvious next step is to open the ChangeLog in $EDITOR after adding the commits (so the user can clean up/consolidate the list) and commit those changes before bumping the VERSION
Steps 6 and 7 of the release guide will be quite trivial as well 13:39
Guest1277 nine: still around? 15:19
nine Guest1277: yes? 15:50
Guest1277 nine: did you manage to get jit related errors when running spectest? If so, which test was it? 15:58
I can get plenty bu only if MoarVM is compiled without optimizations 15:59
*but
nine Those assertions will only trigger in a debug build as they are not compiled in otherwise 16:05
t/02-rakudo/12-proto-arity-count.t .............................. No subtests run 16:16
dogbert17 nine: does the problem disappear if you revert github.com/rakudo/rakudo/commit/49...cc166a916e 17:52
nine dogbert17: yes 20:50
dogbert17 nine: cool, I then we see the same results 21:02
why the change have this effect I don't understand 21:03
s/I // 21:11

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!