|
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 | |