00:01 d4l3k_ joined 00:31 samcv joined 01:01 samcv joined 01:26 MasterDuke joined 01:32 TimToady joined 06:50 dalek joined 06:51 SmokeMachine joined 06:54 domidumont joined 06:56 ilmari[m] joined 06:59 domidumont joined 07:23 SourceBaby joined 07:53 domidumont joined 08:17 zakharyas joined 09:02 lizmat joined 10:36 domidumont joined 12:21 AlexDaniel joined
Geth MoarVM/sync-file-no-uv: f8e6079343 | (Jonathan Worthington)++ | src/io/syncfile.c
Eliminate last libuv usages from syncfile.

Except one mention that is used for sync processes, which will go away soon.
13:06
jnthn Hm, is it me or did spectest get a bit slower in the last 4 days? 13:07
Seems up 5+ wallclock seconds since I last did one back on Wed 13:08
13:09 zakharyas joined
Zoffix jnthn: yes, and Tux's bench is slower. Some commit slowed it down. 13:10
My ~114s stresstest runs are now ~124
AlexDaniel ouch 13:12
Zoffix glances at the commit log 13:14
Worse... statistically, likely I was the culprit
Dunno, could it be io-adoptation branch? 13:18
jnthn Zoffix: That'd be odd, given I saw the jump since I was last working on Perl 6 stuff 13:20
Zoffix OK. I'll try to narrow it down 13:21
jnthn Hmmm... 14:04
Zoffix ?
So far stresstested commits fb7dd8a, 3488914, a47a78f and they show 118 secs. Dunno if that's before or after the slowdown... probably before. 14:05
Based on logs, it happened sometime between May 31st and June 1st: irclog.perlgeek.de/perl6-dev/searc...mp;q=ZOFVM 14:06
.. and 3488914 was done on the 2nd :/ 14:07
jnthn Trying to figure out how to get :merge style functionality wired up with libuv 14:08
AlexDaniel \o/ 14:13
jnthn And every attempt so far failed in some way
grr
Zoffix Narrowed down the slow down to 9 commits; 5s difference between them 14:27
jnthn Urgh, I'm converging on "there isn't a way to do this" :S 14:28
Zoffix :o 14:29
jnthn I mean, I can cheat
But I was really hoping to get the same descriptor bound to both
Well, cheating works :) 14:33
Geth MoarVM: 9f7d93d561 | (Jonathan Worthington)++ | 3 files
Support merge_bytes in async proc ops.

Emits stdout and stderr data into the same stream. Ideally we might have been able to get the same "handle" on both, but it seems there is no way to make this happen.
14:38
jnthn Also just realized: I'm doing this so I can re-work Proc to use Proc::Async 14:56
But :merge was busted and so disabled in Proc :P
The other features are shell, and binding filehandles to stdin/stdout/stderr 15:02
Zoffix *sigh* I'm having trouble pin-pointing slowdown.
2500e50 121
79b8ab9 119
b879060 117
[Coke] could be a few gradual ones in a row
Zoffix tries 01d948d and then will try to these again
jnthn Oh, but guess we can do shell in Perl 6 space 15:04
Geth MoarVM: 6a372ac42e | jnthn++ | src/moar.c
Unbust VM initialization on Windows.

We need the NFG data structures set up ahead of bootstrap, since we make a string constant that contains a synthetic on Windows (\r\n).
15:40
MoarVM/sync-file-no-uv: 4f80023c02 | jnthn++ | src/platform/win32/io.c
Add missing cast to silence a warning on Windows.
16:04
MoarVM/sync-file-no-uv: fd6ece3683 | jnthn++ | src/io/syncfile.c
strerror is correct on Windows already.

And _strerror is something else that takes a string, not an int.
MoarVM/sync-file-no-uv: 9482524ed3 | jnthn++ | src/io/syncfile.c
Be sure to open in binary mode on Windows.

We handle our own translation, and don't want duplicate translation happening.
16:37
MoarVM/sync-file-no-uv: 9a69711c37 | jnthn++ | src/io/syncfile.c
Also set binary mode on handle made from fd.

This happens with the standard handles. Without this, a \r\n that we output when redirecting to a file on Windows would turn into \r\r\n.
jnthn Tests look a lot cleaner with that fixed :P 16:38
Geth MoarVM/master: 9 commits pushed by (Jonathan Worthington)++, jnthn++ 16:48
jnthn There we go, another piece of the puzzle landed :) 16:50
Zoffix \o/ 17:04
timotimo fantastic
17:28 domidumont joined
lizmat jnthn: could you summarize what you've done the past week, in one or more lines ? 18:25
lizmat has been away a lot and probably missed quite a few things
jnthn lizmat: Refactored NQP's I/O to have a file handle object, which then uses the VM-backed decoder, just like the Rakudo file handles now do. Eliminated the char-level I/O ops from MoarVM, thus finishing the work to decouple I/O and encodings. Finally, reworked synchronous file I/O in MoarVM to not use libuv. 18:42
lizmat jnthn++ :-)
this has not landed in nom, has it ? 18:43
jnthn It all has except the very final part.
Which is in MoarVM master, but there wasn't a version bump yet.
(Only merged a couple of hours ago) 18:44
18:44 ilmari joined
lizmat would you be ok with a version bump ? 18:44
jnthn Yeah, but spectest on OSX first ;-) 18:45
Windows and Linux are good with it
jnthn bbiab 18:47
18:49 zakharyas joined
lizmat jnthn: looks clean apart from a flapper in t/spec/S12-attributes/class.t :-( 19:13
bumping nonetheless
jnthn: could you elaborate a bit on why not using libuv for synchronous file I/O is a good thing ? 19:30
19:47 dogbert17 joined
japhb lizmat: It allows passing synchronous filehandles between threads without libuv exploding. This comes up particularly often in code that e.g. starts a task to handle reading $*IN 19:59
lizmat japhb: ah, ok, so the same thing he did for sockets last week 20:01
japhb This was pretty high on my list of wants for TUI applications, because I want to be able to process raw terminal inputs (like converting special escapes into function key or mouse events) in the background so user code doesn't have to care about that.
Oh, and of course: jnthn++ :-) 20:02
lizmat japhb: well, it just landed in Rakudo, so there's nothing stopping you now :-) 20:03
nwc10 I'm sure that I should know the answer to this, but why is this only needed for synchronous file handles. I'm infering that there's some reason why it's (already) safe to pass asynchronous filehandles between threads, and hence asking what makes that safe already/what makes it different from synchronous file handles?
lizmat afaik, libuv does *not* passing asynchronous file handles between threads 20:04
japhb lizmat: Well, except tuits. But I'm anxious to see if this fixes my raw terminal input lockup problem, so I'll make some time for that. :-)
lizmat and since before this all file handles were asynchronous, you couldn't do that in Rakudo
nwc10: at least that's my understanding of it 20:05
japhb: ah yes, those pesky tuits :-)
jnthn Note that one more step is needed for $*IN, $*OUT, and $*ERR (I hope a fairly small one); those are still to be switched over for the TTY case 20:24
With luck, will do that tomorrow 20:25
Will blog soon (not soon enough for this week's weekly though :)) about the various reasons for the changes :)
lizmat cool, looking forward to reporting it in next week's P6W :-) 20:36
and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/06/05/...illed-tap/ 21:41
jnthn lizmat++
timotimo nwc10: it's safe to pass asynchronous file handles between threads because all work on it is done on the event loop thread, of which there is only one, so the underlying libuv handle (which is the only vulnerable part) doesn't get passed around at all 23:17
colomon lizmat++ 23:19