github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:02 nativecallable6 left, quotable6 left, greppable6 left, shareable6 left, squashable6 left, committable6 left, sourceable6 left, evalable6 left, tellable6 left, statisfiable6 left, coverable6 left, bisectable6 left, bloatable6 left, reportable6 left, linkable6 left, unicodable6 left 01:03 notable6 left, releasable6 left, benchable6 left, statisfiable6 joined, committable6 joined, greppable6 joined 01:04 benchable6 joined, coverable6 joined, tellable6 joined, notable6 joined, linkable6 joined, sourceable6 joined, nativecallable6 joined, shareable6 joined, evalable6 joined 01:05 squashable6 joined, quotable6 joined, bisectable6 joined, bloatable6 joined, releasable6 joined, reportable6 joined 01:06 unicodable6 joined 02:06 leont left 04:43 linkable6 left, evalable6 left 04:45 linkable6 joined 04:46 evalable6 joined
timotimo good, good 06:39
how bad can it really be to just include the memmem implementation twice 06:56
Geth MoarVM/dump-finds-moar-bytecode-header: 77cd533073 | (Timo Paulssen)++ | src/moar.c
Give a specific error when MVM_platform_mmap_file fails

perhaps factoring this out to a platform function as well would be a good idea, like MVM_platform_describe_mmap_failure.
07:11
MoarVM/dump-finds-moar-bytecode-header: feb8a1e831 | (Timo Paulssen)++ | 3rdparty/freebsd/memmem.c
Make memmem impl static

we only include memmem from files that actually use it, which up until now was just a single file, string/ops.c; so far it has been fine to just include the implementation of memmem from the header file, but now that moar.c also uses it for --dump support, it would cause duplicate definition of symbol errors.
memmem is small, and changing the build system can be annoying. I think it's fine to Do This Later.
MoarVM/dump-finds-moar-bytecode-header: 325aa4088d | (Timo Paulssen)++ | 3 files
Make memmem impl usable from multiple places

by making 3rdparty/freebsd/memmem.c part of the objects lists and removing the implementation from the memmem header file
07:31
timotimo turned out the "make it static" thing wasn't going to work out without even more hacks 07:32
Geth MoarVM/dump-finds-moar-bytecode-header: 98457cdbf4 | (Timo Paulssen)++ | src/platform/memmem.h
don't forget to pull in stdint to get size_t
07:35
MoarVM/dump-finds-moar-bytecode-header: 004ce49c28 | (Timo Paulssen)++ | src/platform/memmem.h
don't forget to pull in stdlib.h to get size_t
08:22
timotimo *ahem*
Geth MoarVM/master: 4 commits pushed by (Timo Paulssen)++ 09:22
timotimo bam, a feature
10:05 vrurg_ joined 10:06 vrurg left, Kaiepi left 10:10 Kaiepi joined 10:12 kawaii left, tbrowder left 10:13 tbrowder joined 10:14 Kaiepi left, camelia left, Kaiepi joined 10:20 camelia joined 10:35 kawaii joined
Geth MoarVM: c3941772c2 | (Timo Paulssen)++ | tools/macroify_mallocs.p6
commit "macroify mallocs" script

it turns mallocs and callocs of a fixed format to using a macro that has the name of the "type" being allocated as an argument. This allows not only to mention the type only once in the alloc, but also to trace allocations not just by size ... (5 more lines)
10:41
timotimo i can't find the patch any more that adds these functions, lmao
10:42 kawaii left 10:49 kawaii joined 10:54 travis-ci joined
travis-ci MoarVM build errored. Timo Paulssen 'commit "macroify mallocs" script 10:54
travis-ci.org/MoarVM/MoarVM/builds/722452093 github.com/MoarVM/MoarVM/compare/7...941772c259
10:54 travis-ci left
timotimo this was not a commit that was supposed to be able to fail 11:05
11:06 kawaii left 11:08 kawaii joined
timotimo aha i found the patch 11:22
nwc10 I know this feeling 11:37
The command "sudo -E apt-add-repository -y "ppa:ubuntu-toolchain-r/test"" failed and exited with 1 during .
11:41 kawaii left, Util left 11:43 kawaii joined
timotimo huh 11:57
paste.centos.org/view/876a3c6a if you've ever wondered what kind of stuff nqp deserializes while running an empty program 12:11
the number at the end is the index in the serialization context 12:12
oh and the hex value is the address of the serializaiton context body 12:13
12:15 kawaii left, kawaii joined 12:33 Util joined 12:38 kawaii left 12:39 Util left 12:40 kawaii joined
timotimo the output from tracing confuses me a little bit 12:45
i see a whole lot of the deserialization work loop being entered with a stable or something in the worklist queue, but then nothing happens
12:51 Util joined
timotimo my end goal is to instrument (in whatever way is most convenient) moar so it can give all information needed to figure out as exactly as possible how deserialization comes to be during startup and run of a program 13:05
13:13 vrurg joined
timotimo i could imagine a hex viewer in one pane and some clickable navigation on the other side 13:14
13:15 vrurg_ left 15:13 MasterDuke joined
MasterDuke timotimo++ 15:21
tellable6 2020-08-25T17:06:37Z #raku <codesections> MasterDuke: ha :D I guess the question I *should* have asked is whether the `candidates` array returned by .candidates is sorted in any particular way
15:48 zakharyas joined 16:44 sena_kun joined 19:48 sena_kun left 21:34 zakharyas left 21:59 Kaeipi joined 22:01 Kaiepi left 23:34 AlexDaniel left