github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:40 evalable6 left, linkable6 left 00:41 evalable6 joined 00:42 linkable6 joined 04:04 squashable6 left 04:07 squashable6 joined
nwc10 good *, #moarvm 07:05
nine: it appears to be Friday. 07:06
07:28 Kaeipi left 07:29 patrickb joined, Kaeipi joined 07:35 Altai-man joined
nine amazing :) 07:44
moon-child still thursday overhere 07:46
;<
nine That's clear evidence that it's just plain better here than there!
moon-child I agree - here is definitely better than there 07:47
08:11 sena_kun joined 08:12 Altai-man left 08:26 domidumont joined 09:10 Kaeipi left, Merfont joined 09:24 Merfont left 09:25 Merfont joined 10:23 zakharyas joined 10:27 domidumont left 10:29 domidumont joined 10:31 squashable6 left, squashable6 joined 12:10 Altai-man joined 12:13 sena_kun left
timotimo the glass is always fuller on the other side 12:35
12:51 zakharyas left 15:50 Merfont left 15:57 zakharyas joined 16:11 sena_kun joined 16:13 Altai-man left 17:46 domidumont left
Geth_ MoarVM/P6opaque-spesh-must-inline-bigint-value-lookup: 9fbcdb4de6 | (Nicholas Clark)++ | src/6model/reprs/P6opaque.c
P6opaque's `spesh` must handle P6bigint values inline, as some are too big.

P6opaque's `spesh` will attempt to take a concrete P6bigint known value and convert it to a `MVM_OP_const_i64`. This doesn't work if big integer's value is to large than an MVMint64.
Previously the code was not considering this corner case. It was calling ... (12 more lines)		 19:47
nwc10 PR coming soon, when I've double checked something.
20:10 Altai-man joined 20:13 sena_kun left
Geth_ MoarVM: nwc10++ created pull request #1386:
P6opaque's `spesh` must handle P6bigint values inline, as some are too big		 20:21
20:30 MasterDuke joined
MasterDuke last night i made the nursery much larger `#define MVM_NURSERY_SIZE 4194304*2*2*2*2` and did a run of that code that causes the panic 'SC index out of range' (overnight, it took much longer with the larger nursery) 20:34
however, the reason i made the nursery larger was to hopefully get some other error because of the poisoning since i was also running with GC_DEBUG = 3 20:35
given how much longer that run took, any reason to try and use it, since it appeared to just have the same error as the shorter runs with a normal size nursery?
nwc10 good question. I don't know. I don't know who else is awake 20:42
20:51 patrickb left
MasterDuke i think it's early enough for nine to still be around, but maybe not 20:52
jnthn Wait, is GC_DEBUG=3 the one that runs GC every allocation? 21:03
nwc10 yes
jnthn Oh. That renders the larger nursery useless then.
nwc10 oh, I ssee
:-)
you are more awake than I am
jnthn I'd forgotten what 3 did yesterday. Sorry.
MasterDuke ha, whoops 21:04
jnthn It's a little misleading in that 2 is just 1 with more checks, but 3 is something quite different
MasterDuke hm, then is there some other way to try to trigger that poisoning, instead of getting all the way to the panic? 21:05
jnthn Poisoning? 21:06
Ah, getting one of the GC_DEBUG traps to trigger, you mean?
MasterDuke yep 21:07
jnthn Sometimes trying a range of different nursery sizes can help
I never wrote anything to automate doing that
MasterDuke hm, that seems like it could take a while. but i guess i could recompile with optimization back on to speed things up and then recompile if i get a trap 21:11
jnthn Yes 21:13
Is this the spesh candidate bug hunt? 21:14
Or another one?
MasterDuke another. github.com/rakudo/rakudo/issues/4038
i have no particular connection to this bug, i just happened to repro it and then got sniped into trying to track it down 21:16
21:16 Kaiepi joined 21:19 zakharyas left
nwc10 Geth_ announces new PRs. Should issues be announced too? It's not like we have a flood (of issues, or of chat) 21:20
MasterDuke i've wondered that too 21:24
jnthn I'm fine with them being announced here; not sure what to tweak to make it happen 21:28
MasterDuke jnthn: should things work fine in general (i.e., run, if slowly, but not segv) with a tiny nursery (256) and GC_DEBUG=3? 21:37
nwc10 jnthn: nor am I. I am 100% unfamiliar with how github does stuff, so I can't even act on this: 21:39
21:35 < tyil> nwc10: can you check which events are being sent to Geth through the webhook right now?
21:35 < tyil> perhaps it's just as simple as checking a box :>
jnthn MasterDuke: Um, unless you try to allocate an object larger than 256 bytes, but I think it should detect that anyway 21:41
nwc10 I had a look at the summary of open issues, and I found this and cried: github.com/MoarVM/MoarVM/issues/1275
not because it's a stupid question. Not at all
but because I had thought some weeks ago (when finding bugs in dyncall) that "oh my, these thigns don't even try to support structs by value" 21:42
they are an 80% or even 90% solution
but 100% is hard
MasterDuke jnthn: hm, running the example code i get `free(): invalid pointer. Aborted (core dumped)`, and with MVM_SPESH_DISABLE=1 i get `MoarVM panic: Invalid owner in item added to GC worklist`. but maybe this is DIHWIDT 21:43
nwc10 there's a reason why XS (and equivalent) are not, um, trivially re-implementable with FFI
there are at least two reasons. structs by value
and APIs implemented (or partialy implemented) by macros 21:44
eg zlib
jnthn nwc10: I thought I read somewhere that libffi can do it, but also I remember reading that it's compiler-specific how such things happen... 21:47
nwc10 I can't think that it's compiler specific. It has to be ABI specific. But the minimal stuff that I've read is that it's pretty much insane 21:48
jnthn Hm, but if the ABI doesn't lay down how to do something (and I thought that was the case here) but compilers want to support it? 21:49
nwc10 in that, you can't second guess the ABI specs about which register or registers to use. Or the stack. Probably depending on size and who knows what else (alignment constraints, phase of the moon, clearly I'm writing an arrogant blog psot here)
I *thought* that it had to, but the only ABI I skimmed recently was sparc 21:50
and even then, it seems that there's the ABI document, and what the compilers actually do (sign extension on 32 bit parameters)
(contradicting the docs, which say that unsigned 8, 16 and 32 bit values are *not* sign extended) 21:51
I sort of gave up at that point
jnthn OK, it looks like I'm wrong, but omg stackoverflow.com/questions/577666...n-assembly
"there is a recursive algorithm that is used to determine if a structure can be passed in a combination of general purpose registers / vector registers / X87 FPU stack registers" :D 21:52
nwc10 I was about to quote *exactly that*
oh, thing I learned last year 21:53
the ABI for a variadic function is not the same as for a function with fixed parameters
for x86_64, a function with ... ends up passing the number of parameters in one of the CPU registers
whereas a function with fixed parameters does not
so don't cast pointers from one to the other and call through a pionter 21:54
even with the "correct" parameter count
"last year". Mmm. I think this was 6 years ago
22:50 SmokeMachine left 22:51 SmokeMachine joined
Altai-man The release is planned to be today. If there is anything preventing a MoarVM one, please ping me, otherwise enjoy. :) 23:05
Geth_ MoarVM: 3c5deb2f61 | (Jonathan Worthington)++ | src/6model/reprs/CStr.c
Implement serialize/deserialize of CStr REPR

As reported in github.com/rakudo/rakudo/issues/2209 the lack of this can sometimes end up blocking precompilation.		 23:19
MoarVM: 76ea45804a | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/CStr.c
Merge pull request #1380 from MoarVM/serialize-cstr

Implement serialize/deserialize of CStr REPR
jnthn Altai-man: Thanks, I coulda forgotten to make sure ^ ended up in the release if you'd not mentioned that... 23:20
(It's very low risk; it can only make something that had used to throw an exception work)

Powered by Cro and the Raku® Programming Language.

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

Thank you!