github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: lizmat assigned to niner Issue Negative indexes with end of buffer semantics github.com/MoarVM/MoarVM/issues/1024
fa3411007d | (Stefan Seifert)++ | src/6model/reprs/VMArray.c

Treating negative offsets as counting from the end of the array was meant to provide consistency with other array ops. Turns out however that the right course of action may be to remove this magic from other ops, too. The magic does not reflect the semantics, Perl 6 actually needs. Fixes GH #1024		 10:15
lizmat again hopes that nine doesn't mind
brrt \o 13:18
I may be easily impressed, but rust-lang.org looks a bit better these days 13:32
we need a bunch of operators for floating points 13:40
lizmat brrt: such as ? 13:41
fwiw, I would look at vm ops for rationals earlier :-)
mornfall (floats are eww but unavoidable, sadly) 13:42
brrt oh, I mean, I need a bunch of floating point operators for the expression JIT :-) 13:52
small-rational opcodes don't seem like *such* a bad idea, but it should be possible to get equivalent performance with good JITting 13:53
from my perspective, I'd rather have as few as possible ops 13:55
jnthn I've pondered VM ops for rationals, but decided against. Better make the effort on EA and eliminating the allocations etc. that makes their HLL impl costly. 13:58
Which'll also make Int math faster along the way. 13:59
And yeah, I'd like less ops too. We've been growing a range of invoke ops (invoke normal, invoke native, invoke spesh plugin), and we could replace numerous of our ops today with an "invoke vmcall" or some such (which would just be the VM equivalent of a syscall). 14:00
All the I/O for example
That'd let us regularize the argument checking and then eliminate a bunch of it 14:01
brrt +1 14:10
I like that idea 14:11
One thing I think that maybe interesting 14:12
a local dynamic allocation op
if the HLL can prove that an allocation doesn't escape, then we can have it destroyed at the point of leaving, and put any allocation pressure on the GC 14:14
jnthn Yeah, but we then also have to prove that :)
For memory safety
brrt Hmmm
jnthn Which is the same work EA would have to do
brrt Well, this adds some flexibility, in that you don't have to know ahead of time how much you allocate? 14:15
nine lizmat: ^^^
yoleaux 09:20Z <lizmat> nine: looks like NQP 3fe17a683 suddenly gave end-of-buffer semantics to negative indexes on read-intX, was that intentional? If so, I guess I need to move the test for negative indices to the setting
lizmat starts bumping and reverting 14:59
nine just pushed the revert 15:00
lizmat has bad news for nine 18:07
lucasb /o\ 18:16
lizmat had to reopen github.com/MoarVM/MoarVM/issues/1022
nine Ah, yes. writeint needs the same treatment as readint 21:42
Will do that tomorrow

Powered by Cro and the Raku® Programming Language.

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

Thank you!