github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
timotimo this was not a commit that was supposed to be able to fail 11:05
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 .
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
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
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
timotimo i could imagine a hex viewer in one pane and some clickable navigation on the other side 13:14
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!