|
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
|
|||