00:57 brrt joined 05:49 mojca joined, mojca left
nwc10 "we have unknown Moar users?" "well, we're about to find out" 05:53
05:53 domidumont joined 05:59 domidumont joined, brrt joined
brrt good * #moarvm 06:00
so, the other side of the equation is, why not do copy uppropagation 06:14
eh
const
the tl;dr is: rather than have the register allocator do the work to ensure we never spill a const
why not replicate all const nodes 06:15
(actually, i know part of the answer, which is that if we do that, we make common subexpression elimination that much more complex)
but still, the idea that a const node always has just one referent, and that is not a copy, that seems like a legit optimizaton
makes for better tiling, too 06:16
06:46 brrt joined 06:51 AlexDaniel joined
brrt so i'm going to put it on the optimizations queue 07:38
idea 07:57
07:58 zakharyas joined
brrt what if i add some functionality to insert a breakpoint in the JIT compiler at a specific point, and, what if i hide these things behind a debug compile flag 07:58
08:56 avarab joined
jnthn morning o/ 08:59
09:00 Voldenet_ joined
jnthn brrt: At some point we'll need to handle users inserting breakpoints into optimized code and how we'll cope with that :) 09:04
brrt thats actually a decent question
jnthn The const copy thing is the classic phase order issue. I guess "do CSE first" might be a way out of it.
brrt uhuh
jnthn But there's no general "best order" for optimizations.
If you know they all converge you can iterate to a fixed point
brrt part of the answer is 'make sure you have a 'user level breakpoint'
nwc10 I thought that Knuth's "best order" was don't :-)
or, more "don't. don't. oh, go on then, if you really have to"
brrt well, some opts make some others impossible
so yeah
jnthn nwc10: Life's a bit different for us, since we're trying to make the user's code run fast enough that *they* can follow the Knuth advice :)
nwc10 you and your sensible answers :-) 09:05
09:05 Voldenet joined
jnthn is surprised he can answer at all after sleeping pretty awfully :S 09:06
Ah, time to kill off write_str form the I/O vtable thingy 09:07
Geth MoarVM/remove-sync-char-io: 21de1c453f | (Jonathan Worthington)++ | 2 files
Remove now-unused string constants.
09:15
MoarVM/remove-sync-char-io: e993fe5294 | (Jonathan Worthington)++ | 5 files
Re-implement print/say debug output ops.

They now encode and then write the bytes to the handle, in preparation for the string-based output API being removed.
09:31
jnthn Righty, *now* I can kill it off :) 09:32
Geth MoarVM/remove-sync-char-io: bfca6545e8 | (Jonathan Worthington)++ | 7 files
Remove string output from I/O layer.

This completes the removal of char-level I/O.
09:37
jnthn Well, sort of
09:55 AlexDaniel joined 09:58 committable6 joined
Geth MoarVM/remove-sync-char-io: c1805fc76a | (Jonathan Worthington)++ | src/io/syncfile.c
Remove use of decode stream in syncfile.
10:56
Zoffix \o
I mean \o/
nwc10 stupid question, I think - what is it about that commit that is particularly \o/ ? 10:58
jnthn I'm not sure :P 10:59
Except the next step for syncfile will be eliminating libuv there
Zoffix Won't this work make stuff like `await start get` not crash?
jnthn Zoffix: Not that step alone, no, but that's what I'm working towards, yes :) 11:00
Zoffix Well, the \o/ was about the general thing :D
jnthn Lunch time; bbl 11:13
11:20 domidumont joined
[Coke] trac.macports.org/ticket/54259 , btw. one person reporting a build error on an old version of OS X. 12:41
jnthn Heh, so I get back to my keyboard and the first thing I see is a tweet saying github have major service outrages... 12:42
*outages
lizmat yeah, my last push took about 30 seconds before it got through
jnthn timotimo: ^^ trac thing is telemetry related 12:43
Geth MoarVM/remove-sync-char-io: dff6a4198f | (Jonathan Worthington)++ | 3 files
Eliminate decodestream for syncstream.

And also, as part of that, syncpipe.
13:08
jnthn Alrighty, I think I'm going to merge this remove-sync-char-io branch 'cus, well, the char I/O is removed 13:09
And then will make a separate branch for giving syncfile its libuv-sectamy
syncstream is harder
Because of syncpipe still using it
Which is tied to libuv because of process stuff 13:10
Meaning sorting it out depends on the rewrite of Proc in terms of Proc::Async
That in turn depends on making Proc::Async on JVM 13:11
nwc10 I was about to type "that tower only has 4 yaks", and then a fifth appeared
jnthn As well as making Proc::Async do the things that Proc does but Proc::Async does not
nwc10 six
jnthn Yeah, indeed
This will in turn let us stop maintaining two sets of proc code 13:12
Which will be nice
Geth MoarVM/master: 12 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...dff6a4198f
13:13
jnthn 23 files changed, 182 insertions(+), 764 deletions(-) 13:14
lizmat whee
jnthn That's the kind of merge I like :)
brrt :-o wow 13:16
jnthn++
anyway, re: breakpoint insertion 13:27
i'm not sure if we do that at all at this point, and if it needs VM-level support 13:28
jnthn We don't yet. It will. 14:34
Remote debug API is somewhere on my list of things to design :) 14:35
brrt okay, well 14:37
we can, if we're JITting, signal ourselves a breakpoint interrupt
that's pretty easy
not sure if it is the right thing to do, though
i'm wondering if there isn't some data flow analyzer for assembly code 14:40
jnthn digs his slightly frazzled brain back into syncfile 14:41
15:10 brrt joined 15:14 KDr2 joined
Geth MoarVM/sync-file-no-uv: 3734a1dcf8 | (Jonathan Worthington)++ | src/io/syncfile.c
Eliminate libuv in the heart of syncfile.

Still a handful of uses left, still be be eliminated.
15:15
jnthn Happily, that doesn't regress spectest. 15:17
Geth MoarVM/sync-file-no-uv: e5ada450a2 | (Jonathan Worthington)++ | src/io/syncfile.c
Implement truncate without libuv.
15:25
15:29 AlexDaniel joined
Geth MoarVM/sync-file-no-uv: fef4f2e9b4 | (Jonathan Worthington)++ | 3 files
Re-implement flush without using libuv.

The Windows part is so far untested, so may have issues.
15:37
[Coke] jnthn: is the goal to completely remove libuv? 15:38
jnthn [Coke]: Only from sync I/O 15:39
For async, threading abstractions, etc. it's staying
Basically, it's going away for the places where we've been having trouble with the handle sharing issues 15:40
Where you couldn't accept a sync socket on one thread and then hand it off to another to work with (fixed already), or do stuff like prompt on a thread (what I'm sorting out now) 15:41
In those cases the APIs are relatively portable anyway 15:42
Enough for now...a bit tired. 15:48
brrt okay, breakpointing env var is on its way 15:53
breakpointing env var works 15:56
16:21 domidumont joined 16:37 robertle joined 17:21 buggable joined 19:36 AlexDaniel joined 20:59 geekosaur joined 22:07 dogbert17 joined 22:54 sivoais joined
samcv good ???? 23:08
buggable ???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 14 ballots submitted by 10 users! DRUM ROLL PLEASE!... 23:59