github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:56 Kaiepi left 01:01 Kaiepi joined 01:34 sena_kun joined 01:36 Altai-man_ left 02:09 Kaeipi joined, Kaiepi left 02:12 Kaeipi left 02:14 Kaeipi joined 03:33 Altai-man_ joined 03:36 sena_kun left 05:20 vrurg left 05:21 vrurg joined 05:34 sena_kun joined 05:36 Altai-man_ left 06:39 brrt joined, domidumont joined 06:42 domidumont left 06:52 domidumont joined 07:31 brrt left
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"
07:33 Altai-man_ joined
nwc10 I can't find this in the docs. 07:34
07:36 sena_kun left
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
07:50 Kaeipi left 07:53 Kaiepi joined, domidumont left 08:16 domidumont joined
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
09:24 zakharyas joined 09:34 sena_kun joined 09:36 Altai-man_ left
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
11:13 zakharyas left 11:14 zakharyas joined
Geth MoarVM: 80ba23a7d1 | (Stefan Seifert)++ | docs/ChangeLog
Update ChangeLog for 2020.02 release
11:15
11:19 hankache joined 11:33 Altai-man_ joined
nine Steps 1-3 of the release guide complete (via tools/release). 11:35
Actually steps 1-4 with the above commit 11:36
11:36 sena_kun left 12:02 zakharyas left
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
12:46 lucasb joined, Kaiepi left 12:47 domidumont left 12:49 Kaiepi joined
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
13:23 hankache left 13:34 sena_kun joined 13:36 Altai-man_ left
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
13:59 zakharyas joined 14:41 colomon_ left
Guest1277 nine: still around? 15:19
15:33 Altai-man_ joined 15:36 sena_kun left
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
16:17 zakharyas left 16:25 zakharyas joined 16:54 domidumont joined 17:25 domidumont left 17:27 domidumont joined 17:32 domidumont left 17:33 domidumont joined 17:34 sena_kun joined 17:36 Altai-man_ left 17:47 mtj_ left
dogbert17 nine: does the problem disappear if you revert github.com/rakudo/rakudo/commit/49...cc166a916e 17:52
18:07 domidumont left 18:08 patrickb joined 18:11 rba[m] left 18:12 AlexDaniel` left 18:29 rba[m] joined 18:30 rba[m] left 19:04 AlexDaniel` joined 19:29 zakharyas left 19:33 Altai-man_ joined 19:36 sena_kun left 19:43 domidumont joined 19:44 rba[m] joined 19:47 domidumont left
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
21:30 zakharyas joined 21:34 sena_kun joined 21:36 Altai-man_ left 22:40 zakharyas left 23:33 Altai-man_ joined 23:36 sena_kun left 23:46 lucasb left