Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-17

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 nebuchadnezzar good night
00:02 timotimo turns out i lied
00:03 dalek MoarVM/merge_facts_at_phi: f82b223 | timotimo++ | src/spesh/dump.c:
00:03 dalek MoarVM/merge_facts_at_phi: highlight registers that are written to by PHI nodes
00:03 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/f82b223647
00:03 dalek MoarVM/merge_facts_at_phi: 9f69201 | timotimo++ | src/spesh/facts.c:
00:03 dalek MoarVM/merge_facts_at_phi: fix a sort of bad thinko in iter_facts
00:03 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/9f69201002
00:03 dalek MoarVM/merge_facts_at_phi: cf6f7ae | timotimo++ | src/spesh/ (2 files):
00:03 dalek MoarVM/merge_facts_at_phi: "use"ing facts from guards now works even for merged facts
00:03 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/cf6f7ae6f8
00:08 dalek MoarVM/merge_facts_at_phi: 083d766 | timotimo++ | src/spesh/optimize.c:
00:08 dalek MoarVM/merge_facts_at_phi: fix comment
00:08 dalek MoarVM/merge_facts_at_phi: review: https://github.com/MoarVM/MoarVM/commit/083d766693
00:12 timotimo cool, spec tests are also clean with this
00:12 timotimo could someone do me a favor and smoke the ecosystem with that branch applied to moarvm?
00:20 timotimo one annoying thing is that the ecosystem isn't clean :(
02:02 zakharyas joined #moarvm
04:02 FROGGS_ joined #moarvm
05:53 camelia joined #moarvm
06:17 camelia joined #moarvm
06:21 camelia joined #moarvm
08:04 FROGGS_ nebuchadnezzar: ohh
08:05 FROGGS_ I'll fix that
08:06 nebuchadnezzar FROGGS_: I made a pull request
08:09 dalek MoarVM: 309561c | (Daniel Dehennin)++ | Configure.pl:
08:09 dalek MoarVM: Use CPPFLAGS is @cflags instead of @ldflags
08:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/309561c7be
08:09 dalek MoarVM: c1cd8c6 | FROGGS++ | Configure.pl:
08:09 dalek MoarVM: Merge pull request #188 from baby-gnu/fix/CPPFLAGS-in-cflags-instead-of-ldflags
08:09 dalek MoarVM:
08:09 dalek MoarVM: Use CPPFLAGS is @cflags instead of @ldflags
08:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c1cd8c6d73
08:09 FROGGS_ nebuchadnezzar++
08:10 Ven joined #moarvm
08:15 rurban joined #moarvm
08:44 Ven joined #moarvm
08:52 donaldh joined #moarvm
10:02 dalek MoarVM: a623b72 | FROGGS++ | src/io/procops.c:
10:02 dalek MoarVM: remove slash->backslash conversion mess
10:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a623b72929
11:57 Ven joined #moarvm
13:09 timotimo FROGGS_: do you think i should store an "is a tty" flag inside SyncStreamData?
13:10 FROGGS_ why do we want to store such a flag?
13:11 FROGGS_ dont we want to just map "foo".IO.isatty to an nqp::isatty op?
13:14 FROGGS_ though I guess the method would be called more like isa-tty or is-a-tty or just tty
13:15 nwc10 arguably one also wants "is a socket?" "is a pipe?" (might not be a difference) "is char special?" "is block special?" and "is a symlink?" at the same level
13:15 nwc10 so, possible op explosion
13:15 nwc10 and probably some stuff I've forgotten, including "doors" on Solaris.
13:17 timotimo hum.
13:18 timotimo we have an op that gives us the underlying file no of a socket, does that also work for other MVMOSHandle repr'd objects?
13:18 timotimo then we could nativecall to isatty
13:18 nwc10 I don't think one wants to nativecall this. I think it feels better as C code that can be platform specific
13:19 nwc10 but I was more meanig, I don't know for sure if this wants to be one op that is "isatty"
13:19 nwc10 the interface to the C might be better as a "WTF is this then?" op
13:19 nwc10 particularly as one wants to ask this question of both filenames and file handles.
13:28 FROGGS_ nwc10: we already have "foo".IO.l return true if that thing is a symlink
13:29 timotimo that's for a file on the file system, not for an open handle, like stdin and stdout
13:29 FROGGS_ and I would not mind adding ten more methods to that
13:29 FROGGS_ .IO gives you a handle, no?
13:29 timotimo m: say $*IN.l
13:29 camelia rakudo-moar 412559: OUTPUT«False␤»
13:29 FROGGS_ at least something similarish
13:30 timotimo huh
13:30 FROGGS_ m: say $*IN.r
13:30 camelia rakudo-moar 412559: OUTPUT«False␤»
13:33 timotimo well, that's a bit problematic :D
13:33 timotimo non-readable stdin?
13:37 Ven joined #moarvm
13:48 lizmat I would be very much in favour of a nqp::isatty function
13:48 lizmat the other stuff we can look at later, but not having IO.t working, is a pain
13:52 zakharyas joined #moarvm
14:01 FROGGS_ lizmat: t is for tty?
14:01 lizmat yup
14:01 lizmat m: $*IN.t
14:01 camelia rakudo-moar 412559: OUTPUT«Cannot find method 'isatty': no method cache and no .^find_method␤  in method t at src/gen/m-CORE.setting:17825␤  in block <unit> at /tmp/3nrO_SWlie:1␤␤»
14:01 FROGGS_ :o)
14:03 nwc10 lizmat: I'd like to wait until at least this evening, to see if jnthn has an opinion.
14:04 lizmat sure, no pb, it's been a problem for quite some time already  :-)
14:12 moritz w 13
14:12 moritz sorry
14:23 timotimo https://gist.github.com/timo/2514267f199a91ce1940#file-gistfile1-txt - this is how spesh fares in the benchmark that sets all of an array's slots to 1
14:23 * timotimo AFK
14:23 timotimo maybe someone else wants to impl isatty in the mean time?
14:43 dalek joined #moarvm
17:44 lizmat joined #moarvm
18:00 timotimo jnthn: bindpos and atpos as well as bindkey and atkey ought to be optimized via the repr's spesh method, right?
18:07 jnthn timotimo: Well, but what into? :)
18:08 jnthn timotimo: It's more that we can JIT them as a direct call to the REPR func
18:08 timotimo then we'll still have the switch for the slot type and the check for the incoming argument to be of the right type
18:09 timotimo ah, i hadn't thought of the fact that we'll also have to do resizing for the writing ones
18:10 jnthn Well, I have been thinking of changing how we lay out VMArray a bit
18:10 jnthn To ease threading issues
18:11 jnthn But yeah, we can de-virtualize the REPR calls for now in the JIT
18:11 timotimo mhh, fair enough
18:12 timotimo the signatures for repr ops are all fixed, right?
18:12 jnthn aye
18:12 jnthn So you just need a known type
18:15 timotimo good, i'll have a quick look at implementing that
18:16 nwc10 jnthn: it looks like "isatty" functionality belongs at the NQP OP level, but it's not clear to me that "isatty" (alone) should be an op
18:17 nwc10 (there was more explanation in backscroll)
18:17 nwc10 in that, there are more things than just TTYs that we'd probably like to test for, and having one op for each *I think* feels like too many ops
18:17 nwc10 but you're the designer.
18:22 jnthn dinner now, will ponder
18:22 jnthn &
18:22 jnthn (but yes, would rather not op explosion)
18:27 timotimo shouldn't we rigorously put REG_VAL_F all over the ops that handle _n?
18:28 timotimo bindattr_n and bindattrs_n, for example, currently use REG_VAL for the value
18:35 timotimo why did i say i could have "a quick look" at implementing this m)
18:45 timotimo would i introduce a new MVM_JIT_* type to refer to an object's body, for example? or actually do a bit of memory calculation in the graph.c stage?
18:46 timotimo at least for &register we have a type already
18:47 timotimo .o( and won't we need to put a _F mode on the return values of some _n ops, too?)
18:48 dalek MoarVM: f2937f5 | ugexe++ | build/probe.pm:
18:48 dalek MoarVM: better armv6 and v7 detection
18:48 dalek MoarVM:
18:48 dalek MoarVM: A Linux kernel reports an $arch of `armv7` when a NetBSD kernel on the same machine reports the appropriate $arch as `earmv7hf`
18:48 dalek MoarVM: http://testers.p6c.org/reports/32564.html
18:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f2937f594f
18:48 dalek MoarVM: 51b90f0 | FROGGS++ | build/probe.pm:
18:48 dalek MoarVM: Merge pull request #190 from ugexe/patch-1
18:48 dalek MoarVM:
18:48 dalek MoarVM: better armv6 and v7 detection
18:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/51b90f01d6
18:50 timotimo yeah, i could do it like that, an extra kind that'll just define a little offset
19:05 hoelzro is there something one should keep in mind when *removing* an op?
19:05 hoelzro ex. readline_intfh?
19:07 FROGGS_ an op needs to be turned into an noop but needs to stay
19:07 hoelzro gaaaah
19:07 FROGGS_ because otherwise we might break nqp's stage0
19:07 timotimo aye, the numbers must remain intact
19:08 hoelzro that's what I figured
19:08 hoelzro ='(
19:09 timotimo we have 16bit space for ops :)
19:10 hoelzro still feels off =/
19:22 FROGGS_ if it is not used by stage0 (which has to be the case) we could replace it with a new op
19:22 FROGGS_ but well, we don't have to (yet)
19:25 hoelzro FROGGS_: ok, I'll keep that in mind
19:29 timotimo well, we've got some slots that used to be occupied long ago
19:44 tgt joined #moarvm
19:48 * timotimo is attempting to compile the new devirtualized reprop call implementation for the first time
19:49 FROGGS_ O.o
19:49 FROGGS_ sounds interesting
19:51 timotimo welp, doesn't compile nqp any more
20:03 timotimo halp
20:03 timotimo i must be doing something wrong here
20:07 dalek MoarVM/jit_devirtualize_reprops: 1330eef | timotimo++ | src/jit/ (3 files):
20:07 dalek MoarVM/jit_devirtualize_reprops: WIP on devirtualizing repr op functions
20:07 dalek MoarVM/jit_devirtualize_reprops:
20:07 dalek MoarVM/jit_devirtualize_reprops: instead of using the convenience functions defined in reprconv.c
20:07 dalek MoarVM/jit_devirtualize_reprops: we go through a type argument's known type to its REPR, REPROps
20:07 dalek MoarVM/jit_devirtualize_reprops: and find the function pointer to call.
20:07 dalek MoarVM/jit_devirtualize_reprops: Unfortunately, something seems to be wrong with argument passing
20:07 dalek MoarVM/jit_devirtualize_reprops: OSLT.
20:07 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/1330eef495
21:04 timotimo how do i get a disassembly of a .bin file that MoarVM's jit outputs?
21:06 timotimo objdump -D -b binary -m i8086 seems to give me ... something
21:08 timotimo but -m x86-64 doesn't work at all
21:08 timotimo ah, found it in the clogs
21:08 timotimo objdump -D -b binary -m i386:x86-64 -M intel
21:12 timotimo https://gist.github.com/timo/066bf4ff0981e4ae016e
21:13 timotimo so my thinking was: i'll dereference the pointer to the object (rbx+0x18 seems to be that pointer), then add the offset in the struct to the result to get the struct's member
21:13 timotimo first the STable, then the object itself, then the object's body
21:14 timotimo at offsets 0x10, 0 and 0x18 respectively
21:14 timotimo is that wrong?
21:16 timotimo am i implementing OBJECT_DATA wrong?
21:16 FROGGS_ the offsets sound reasonable
21:17 timotimo well, FWIW, in the debugger the "data" pointer, when decreased by 0x18, gives me a very valid looking MVMArray struct
21:18 timotimo and of course the other values are optimized out >:(
21:23 timotimo but repr_data is 0x8, which is, i would assume, the offset that comes from here: MVMArrayREPRData *repr_data = (MVMArrayREPRData *)st->REPR_data;
21:23 timotimo so st must be 0, but how can that be?
21:24 timotimo do i perhaps have to add another dereference in some place?
21:24 timotimo maybe now i have a pointer to the pointer of the STable?
21:41 timotimo i must somehow be significantly brainfarted or something
21:41 timotimo i don't think i'll figure this out this evening
21:42 timotimo i may just get some early rest so i can drive home safely and comfortably early tomorrow
21:44 FROGGS_ yeah, that might be a better choice than a walk :o)
21:54 kjs_ joined #moarvm
21:55 hoelzro I'm guessing if I want to remove linenoise, I can't remove the interactive member of MVMIOOps, can I?
22:00 camelia joined #moarvm
22:44 dalek MoarVM/jit_devirtualize_reprops: 496c74c | brrt++ | src/jit/ (2 files):
22:44 dalek MoarVM/jit_devirtualize_reprops: Take value of rather than pointer to object stable
22:44 dalek MoarVM/jit_devirtualize_reprops:
22:44 dalek MoarVM/jit_devirtualize_reprops: This would cause a SEGV in JITting direct calls to REPR ops.
22:44 dalek MoarVM/jit_devirtualize_reprops: review: https://github.com/MoarVM/MoarVM/commit/496c74c73e
22:45 brrt joined #moarvm
22:46 brrt btw, very much timotimo++ for coming so far
22:46 brrt my lazy bum hadn't started yet :-)
22:46 timotimo thank you so much for fixing it
22:46 brrt nqp tests pass, as does rakudo tests, spectest running as we speak
22:46 timotimo now is my bedtime, though
22:46 timotimo well, it's only a single repr op so far
22:47 brrt also, try --optimize=0 :-)
22:47 timotimo tomorrow i'll be spending alot of day driving
22:47 brrt if you have the stomach to wait for moarvm like it's 2014
22:47 timotimo haha
22:47 brrt oh, well, you should sleep well then
22:47 timotimo i have --optimize=1 and --asan :)
22:47 brrt our bus factor is low enough as it is
22:48 brrt --asan is also a real killer yes
22:48 brrt but --optimize=0 makes gdb more useful
22:48 brrt or lldb, i guess, if you're into that
22:48 timotimo i ought to be able to make more repr ops devirtualized
22:48 timotimo many, many more
22:49 brrt i think so too
22:49 timotimo like, without too much more thinking or assistance
22:49 brrt i had basically stopped at the point 'but you can optimize the accesses to the single repr op variable' but in reality it isn't very important
22:49 brrt like that's something the exprcomp will do eventually
22:49 timotimo hm?
22:49 timotimo single repr op variable?
22:50 brrt the object to which the repr op function is dispatched
22:50 timotimo btw, if you're interested in a little benchmark, you can have a look at https://gist.github.com/timo/2514267f199a91ce1940
22:50 brrt what's up with that?
22:51 timotimo the file at the far bottom explains it
22:51 brrt i read
22:51 timotimo i had put that file up first, but the big diff bubbled up to the top :(
22:52 timotimo or if you want to do something else, there's a branch that allows the QASTCompilerMAST to access localref decl'd vars as local and local decl'd vars as localref
22:52 brrt hmm
22:52 timotimo it's not working properly, as in: tests fail
22:53 brrt i'll see if i can take a look, but tuits are scarce :-(
22:54 timotimo OK :)
22:54 timotimo i don't want to steal too many of your tuits
22:54 timotimo jnthn already said he could have a look at that branch, too
22:55 brrt :-)
22:55 jnthn (korean food)++
22:55 jnthn timotimo: oh no, I agreed to what? :)
22:56 jnthn Oh, the localref. I should have time tomorrow evening.
22:56 timotimo :D
22:56 timotimo cool
22:56 timotimo brrt just fixed my thinko WRT jitting objbody and stable references to objects in registers
22:56 timotimo so now we have a single repr op devirtualized
22:56 jnthn ah, cool :)
22:56 timotimo atpos_*
22:56 jnthn Does it make much difference? :)
22:56 timotimo didn't test yet
22:57 timotimo i'm en route to bedtimes :)
22:57 brrt that one could, for arrays, even be jitted directly, but i don't want to do an emit-explosion yet
22:57 jnthn yeah
22:57 jnthn I may tweak array stuff to make it more safely jittable too :)
22:57 timotimo jnthn warned there may be a change to the layout of MVMArray in the future
22:57 brrt if we have the exprcomp then it'll be easier to for reprs to jit ops by creating an expression tree
22:57 timotimo <3
22:57 jnthn brrt: Indeed
22:58 brrt i had not considered that before
22:58 brrt that solves something
22:58 timotimo no, it solves EVERYTHING
22:58 timotimo er, sorry, carry on
22:58 brrt :-D
22:58 brrt i should sleep too
22:58 brrt see you!
22:58 jnthn brrt: Might be worth pondering the set of things you want to work on with JIT in the summer, and start getting a grant app together for summer. :)
22:59 jnthn But yes, sleep first. :)
22:59 brrt yes, thanks :-)
23:00 timotimo i'm glad he still answers to the Bart Signal whenever i'm in dire need of his help :)
23:01 jnthn :D
23:01 jnthn hoelzro: (remove interactive member of MVMIOOps) you should get away with that at this point

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary