timotimo wow, tc being 0 inside an MVM_interp_run 00:21
that's novel
with --optimize=0 tc stays non-0, but here i have an unbox_i that blows because the object is low-level-null 00:25
all of this while i'm trying to profile a thing 00:27
looks like it's trying to throw an exception of type X::Multi::NoMatch 00:29
without the profiler it - unsurprisingly - works 00:30
the explosion with the unbox_i happens inside a piece of regex code used by the message method via a few layers of indirection 00:31
samcv wow 01:58
brrt good hi #moarvm 09:52
Geth MoarVM/even-moar-jit: ae9607697a | (Bart Wiegmans)++ | src/jit/linear_scan.c
Factor comparison out of live range heap

I want to maintain two different orders for the live range heap, i.e. on the first_ref ascending order, and on last_ref ascending order, for the values that are supposed to become active and for the values that have been spilled respectively. So I've factored the comparison function out of the live range heap.
A 'generic' binary heap in C would either require dynamic allocation (to maintain space for the temporary when swapping) or be written with macros. I don't find either solution very appealing.
MoarVM/even-moar-jit: b06409d258 | (Bart Wiegmans)++ | 5 files
Register type of allocated spill memory

Use a bucketed free list to manage spill locations, and construct the new local types array during JIT assembly. The GC still needs to be convinced to look at it.
brrt the binary heap thing finally got me to see some of the benefits of c++ 10:01
Geth MoarVM: 78bed96569 | (Jonathan Worthington)++ | 16 files
Stub in setbuffersizefh and IO vtable entry for it

Will be used to enable output buffering and to pick the size of the output buffer.		 13:30
MoarVM: 67f718a6e5 | (Jonathan Worthington)++ | 6 files
Follow op naming conventions consistently.
 13:35
Geth MoarVM: 7405dfa9e0 | (Jonathan Worthington)++ | 2 files
Implement output buffering for sync file handles.

Which can give a big performance improvement when writing lots of small pieces (like a line at a time) to a file.		 14:17
nine So each output handle will now have a malloced buffer. Does that mean the GC has to be made aware of that to correctly estimate memory consumption? 14:21
jnthn We've only typically applied pressure where it's liable to be an issue 14:23
jnthn Also going to add in logic to free the buffer at .close 14:23
(And GC if last gasp)
timotimo if you make gigantic buffers per file, it could even cause a problem, but if we delete the buffer when you close the fh, it's no problem, because you got the file descriptor limit anyway
jnthn But since you run out of handles anyway if you don't .close, and the buffer is not typically large, you'd run out of handles first 14:24
nwc10 you get into this interesting thing here that doesn't seem to be a mandated "feature" of stdio libraries, but all the "sane" ones I've found seem to do it 14:25
which is to flush the output buffer of STDOUT when attempting a read from STDIN
jnthn We
d'oh
We'll have to see if we really need that I guess
nwc10 or, more nuanced, seems to be "flush the output buffer of anything outputing to tty when about to block on the read from a tty"
jnthn If we do then it would be implemented at Perl 6 level
Oh 14:26
nwc10 you need it to make interactive programs behave the was the user expects
jnthn I thought stdio didn't buffer *at all* when it's a tty? 14:26
nwc10 you might be right, but I thought that it tended to be "line buffering"
jnthn Ah, right
nwc10 but the trick described is needed to make "line buffering" work when they did (pseudcode):
jnthn Any feeling is, for now, we'll just not buffer to tty at all
nwc10 print "Tell me your number:";
$number = <>; 14:27
where there's no newline on the prompt string, but the programmer sort of magically assumed that somehow it will appear on the screen before the user starts to type stuff in
jnthn The other thing we need to arrange for is to .flush $*OUT and $*ERR at exit, which I guess we can do with an END block
nwc10 anyway, I should stop being PEBKAC for this keyboard and chair, and go get a train to a different keyboard and chair 14:28
jnthn Ah, and that's why the write-on-read would help
So much output to stdout/stderr is lines already though
So if you are only ever buffering until a line break...I'm wondering when that's even a win 14:29
I figure we'll introduce it slowly, anyways 14:42
For now, so slowly that you need to say :buffer or :4096buffer or so
After that we can switch it on by default for anything you open that isn't a TTY
And then with time for standard handles if they're not bound to a TTY 14:43
travis-ci MoarVM build failed. Jonathan Worthington 'Follow op naming conventions consistently.' 14:44
travis-ci.org/MoarVM/MoarVM/builds/245373104 github.com/MoarVM/MoarVM/compare/7...f718a6e586
jnthn ah, was a MOAR_REVISION bump race 14:45
nine I wonder if nowadays buffering is even important on ttys. Well maybe for ssh sessions over crappy mobile connections. 14:47
timotimo let mosh handle that problem :) 14:48
jnthn nine: iiuc, line buffering means you can only buffer one line at a time
timotimo did you see that thing where you can figure out the password someone's typing based on timing from the ssh packets?
jnthn But 99% of the output people will do with TTYs in Perl 6 is with `say`, I reckon 14:49
timotimo and for the situation "print half a line the nask for input" we have "prmpt" anyway 14:50
which could do the flush for you
jnthn It already does
timotimo splendid
jnthn But I'm saying we won't buffer TTYs *at all* anyway :)
We'll just take the path we do today
So no change
brrt hasn't yet switched to mosh in spite of its obvious benefits 14:57
Geth MoarVM: 888b33d199 | (Jonathan Worthington)++ | src/io/syncfile.c
Clean up output buffer on close and GC free.
travis-ci MoarVM build passed. Jonathan Worthington 'Clean up output buffer on close and GC free.' 16:09
travis-ci.org/MoarVM/MoarVM/builds/245405485 github.com/MoarVM/MoarVM/compare/7...8b33d199ce

Powered by Cro and the Raku® Programming Language.

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

Thank you!