github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
lucasb moar? :) 17:50
brrt \o 20:24
(this is an invitation to spam me with jitbreakage) 20:25
no jitbreakage? hmmm 20:29
dogbert17 brrt: I'm not certain I have any atm 21:10
brrt hehe 21:11
that's good
MasterDuke but if you have any ideas of how to jit param_rn2_*... 21:15
brrt ok, I'll explain the difficulty there
- on the one side, they tend to be evidence that we weren't able to sufficiently spesh this method.... and it's (so far) proven more worthwhile to figure out why that is, than to JIT them. that's also because... 21:16
- they rely on the interpreters' somwehat arcane logic for making sure that when the callee expects a native int, it gets a native int, even if e.g. the caller passed a string 21:17
N years in, I'm not super convinced that was a good design choice. It's not a bad one per se, and it fits the perl community's preference for TIMTWTDI, but if we had, say, exposed only object passing to the compiler, and implemented native value passing strictly as a specialization, I wonder if we'd have a better, simpler system 21:19
dogbert17 brrt: is this function work in progress? github.com/MoarVM/MoarVM/blob/mast...ers.c#L387
brrt (either that, or if we had passed it to the caller's side, where I think it belongs logically)
MasterDuke hm. any idea what's blocking them being speshed then? 21:20
brrt dogbert17: idk, I didn't write them
dogbert17 aha
brrt MasterDuke: they return a struct that holds a union of the result value, and whether or not it was present, and that's then used to dispatch to either an exception or a branch (for the _op_, _on_ variants) 21:21
dogbert17 it seems to be timotimo
or possibly one of his cats :) 21:22
brrt and struct returning tends to differ a bit between compilers... or at least, it isn't as obviously well-specified as scalar
I think the common pattern is to have the lower bits on rax, and the upper bits in rcx 21:23
If I could find some evidence that this was actually what was specified and guaranteed, then I could move forward with implementing it. but I haven't found that evidence
MasterDuke huh 21:24
dogbert17 There are a few places in the codebase where the result of uv_mutex_init isn't checked. Couldn't that be a problem? 21:36
brrt I think it might. Can we handle the problem if it is? 21:38
(and if not, can we move the uv_mutex_init to a place where we can handle the problem?)
dogbert17 where the return value is checked we abort 21:38
brrt hmmm
that sucks
I think we should abort for internal errors only 21:39
dogbert17 aha, here's an example where we check: github.com/MoarVM/MoarVM/blob/mast...ueue.c#L27
brrt yeah, that seems correct
constructing an object is not an obvious place to throw, but it is definitely not outside the realm of the possible 21:40
and an adhoc exception can be caught
an abort() cannot
dogbert17 my bad, I shouldn't have written abort
here's an example of not checking: github.com/MoarVM/MoarVM/blob/mast...Unit.c#L28 21:41
brrt interestingly, we can't throw there 21:42
because it'd interfere with the temp-roots popping 21:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!