nebuchadnezzar good night 00:02
timotimo turns out i lied
dalek arVM/merge_facts_at_phi: f82b223 | timotimo++ | src/spesh/dump.c:
highlight registers that are written to by PHI nodes
 00:03
arVM/merge_facts_at_phi: 9f69201 | timotimo++ | src/spesh/facts.c:
fix a sort of bad thinko in iter_facts
arVM/merge_facts_at_phi: cf6f7ae | timotimo++ | src/spesh/ (2 files):
"use"ing facts from guards now works even for merged facts
arVM/merge_facts_at_phi: 083d766 | timotimo++ | src/spesh/optimize.c:
fix comment
 00:08
timotimo cool, spec tests are also clean with this 00:12
could someone do me a favor and smoke the ecosystem with that branch applied to moarvm?
one annoying thing is that the ecosystem isn't clean :( 00:20
02:02 zakharyas joined 04:02 FROGGS_ joined 05:53 camelia joined 06:17 camelia joined 06:21 camelia joined
FROGGS_ nebuchadnezzar: ohh 08:04
I'll fix that 08:05
nebuchadnezzar FROGGS_: I made a pull request 08:06
dalek arVM: 309561c | (Daniel Dehennin)++ | Configure.pl:
Use CPPFLAGS is @cflags instead of @ldflags
 08:09
arVM: c1cd8c6 | FROGGS++ | Configure.pl:
Merge pull request #188 from baby-gnu/fix/CPPFLAGS-in-cflags-instead-of-ldflags

Use CPPFLAGS is @cflags instead of @ldflags
FROGGS_ nebuchadnezzar++
08:10 Ven joined 08:15 rurban joined 08:44 Ven joined 08:52 donaldh joined
dalek arVM: a623b72 | FROGGS++ | src/io/procops.c:
remove slash->backslash conversion mess
 10:02
11:57 Ven joined
timotimo FROGGS_: do you think i should store an "is a tty" flag inside SyncStreamData? 13:09
FROGGS_ why do we want to store such a flag? 13:10
dont we want to just map "foo".IO.isatty to an nqp::isatty op? 13:11
though I guess the method would be called more like isa-tty or is-a-tty or just tty 13:14
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
so, possible op explosion
and probably some stuff I've forgotten, including "doors" on Solaris.
timotimo hum. 13:17
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
then we could nativecall to isatty
nwc10 I don't think one wants to nativecall this. I think it feels better as C code that can be platform specific
but I was more meanig, I don't know for sure if this wants to be one op that is "isatty" 13:19
the interface to the C might be better as a "WTF is this then?" op
particularly as one wants to ask this question of both filenames and file handles.
FROGGS_ nwc10: we already have "foo".IO.l return true if that thing is a symlink 13:28
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
.IO gives you a handle, no?
timotimo m: say $*IN.l
camelia rakudo-moar 412559: OUTPUTĀ«Falseā¤Ā»
FROGGS_ at least something similarish
timotimo huh 13:30
FROGGS_ m: say $*IN.r
camelia rakudo-moar 412559: OUTPUTĀ«Falseā¤Ā»
timotimo well, that's a bit problematic :D 13:33
non-readable stdin?
13:37 Ven joined
lizmat I would be very much in favour of a nqp::isatty function 13:48
the other stuff we can look at later, but not having IO.t working, is a pain
13:52 zakharyas joined
FROGGS_ lizmat: t is for tty? 14:01
lizmat yup
m: $*IN.t
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ā¤ā¤Ā»
FROGGS_ :o)
nwc10 lizmat: I'd like to wait until at least this evening, to see if jnthn has an opinion. 14:03
lizmat sure, no pb, it's been a problem for quite some time already :-) 14:04
moritz w 13 14:12
sorry
timotimo gist.github.com/timo/2514267f199a9...tfile1-txt - this is how spesh fares in the benchmark that sets all of an array's slots to 1 14:23
timotimo AFK
maybe someone else wants to impl isatty in the mean time?
14:43 dalek joined 17:44 lizmat joined
timotimo jnthn: bindpos and atpos as well as bindkey and atkey ought to be optimized via the repr's spesh method, right? 18:00
jnthn timotimo: Well, but what into? :) 18:07
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
ah, i hadn't thought of the fact that we'll also have to do resizing for the writing ones 18:09
jnthn Well, I have been thinking of changing how we lay out VMArray a bit 18:10
To ease threading issues
But yeah, we can de-virtualize the REPR calls for now in the JIT 18:11
timotimo mhh, fair enough
the signatures for repr ops are all fixed, right? 18:12
jnthn aye
So you just need a known type
timotimo good, i'll have a quick look at implementing that 18:15
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:16
(there was more explanation in backscroll) 18:17
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
but you're the designer.
jnthn dinner now, will ponder 18:22
&
(but yes, would rather not op explosion)
timotimo shouldn't we rigorously put REG_VAL_F all over the ops that handle _n? 18:27
bindattr_n and bindattrs_n, for example, currently use REG_VAL for the value 18:28
why did i say i could have "a quick look" at implementing this m) 18:35
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:45
at least for &register we have a type already 18:46
.o( and won't we need to put a _F mode on the return values of some _n ops, too?) 18:47
dalek arVM: f2937f5 | ugexe++ | build/probe.pm:
better armv6 and v7 detection

A Linux kernel reports an $arch of `armv7` when a NetBSD kernel on the same machine reports the appropriate $arch as `earmv7hf`
  testers.p6c.org/reports/32564.html		 18:48
arVM: 51b90f0 | FROGGS++ | build/probe.pm:
Merge pull request #190 from ugexe/patch-1

better armv6 and v7 detection
timotimo yeah, i could do it like that, an extra kind that'll just define a little offset 18:50
hoelzro is there something one should keep in mind when *removing* an op? 19:05
ex. readline_intfh?
FROGGS_ an op needs to be turned into an noop but needs to stay 19:07
hoelzro gaaaah
FROGGS_ because otherwise we might break nqp's stage0
timotimo aye, the numbers must remain intact
hoelzro that's what I figured 19:08
='(
timotimo we have 16bit space for ops :) 19:09
hoelzro still feels off =/ 19:10
FROGGS_ if it is not used by stage0 (which has to be the case) we could replace it with a new op 19:22
but well, we don't have to (yet)
hoelzro FROGGS_: ok, I'll keep that in mind 19:25
timotimo well, we've got some slots that used to be occupied long ago 19:29
19:44 tgt joined
timotimo is attempting to compile the new devirtualized reprop call implementation for the first time 19:48
FROGGS_ O.o 19:49
sounds interesting
timotimo welp, doesn't compile nqp any more 19:51
halp 20:03
i must be doing something wrong here
dalek arVM/jit_devirtualize_reprops: 1330eef | timotimo++ | src/jit/ (3 files):
WIP on devirtualizing repr op functions

instead of using the convenience functions defined in reprconv.c we go through a type argument's known type to its REPR, REPROps and find the function pointer to call. Unfortunately, something seems to be wrong with argument passing OSLT.		 20:07
timotimo how do i get a disassembly of a .bin file that MoarVM's jit outputs? 21:04
objdump -D -b binary -m i8086 seems to give me ... something 21:06
but -m x86-64 doesn't work at all 21:08
ah, found it in the clogs
objdump -D -b binary -m i386:x86-64 -M intel
gist.github.com/timo/066bf4ff0981e4ae016e 21:12
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
first the STable, then the object itself, then the object's body
at offsets 0x10, 0 and 0x18 respectively 21:14
is that wrong?
am i implementing OBJECT_DATA wrong? 21:16
FROGGS_ the offsets sound reasonable
timotimo well, FWIW, in the debugger the "data" pointer, when decreased by 0x18, gives me a very valid looking MVMArray struct 21:17
and of course the other values are optimized out >:( 21:18
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
so st must be 0, but how can that be?
do i perhaps have to add another dereference in some place? 21:24
maybe now i have a pointer to the pointer of the STable?
i must somehow be significantly brainfarted or something 21:41
i don't think i'll figure this out this evening
i may just get some early rest so i can drive home safely and comfortably early tomorrow 21:42
FROGGS_ yeah, that might be a better choice than a walk :o) 21:44
21:54 kjs_ joined
hoelzro I'm guessing if I want to remove linenoise, I can't remove the interactive member of MVMIOOps, can I? 21:55
22:00 camelia joined
dalek arVM/jit_devirtualize_reprops: 496c74c | brrt++ | src/jit/ (2 files):
Take value of rather than pointer to object stable

This would cause a SEGV in JITting direct calls to REPR ops.		 22:44
22:45 brrt joined
brrt btw, very much timotimo++ for coming so far 22:46
my lazy bum hadn't started yet :-)
timotimo thank you so much for fixing it
brrt nqp tests pass, as does rakudo tests, spectest running as we speak
timotimo now is my bedtime, though
well, it's only a single repr op so far
brrt also, try --optimize=0 :-) 22:47
timotimo tomorrow i'll be spending alot of day driving
brrt if you have the stomach to wait for moarvm like it's 2014
timotimo haha
brrt oh, well, you should sleep well then
timotimo i have --optimize=1 and --asan :)
brrt our bus factor is low enough as it is
--asan is also a real killer yes 22:48
but --optimize=0 makes gdb more useful
or lldb, i guess, if you're into that
timotimo i ought to be able to make more repr ops devirtualized
many, many more
brrt i think so too 22:49
timotimo like, without too much more thinking or assistance
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
like that's something the exprcomp will do eventually
timotimo hm?
single repr op variable?
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 gist.github.com/timo/2514267f199a91ce1940
brrt what's up with that?
timotimo the file at the far bottom explains it 22:51
brrt i read
timotimo i had put that file up first, but the big diff bubbled up to the top :(
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
timotimo it's not working properly, as in: tests fail
brrt i'll see if i can take a look, but tuits are scarce :-( 22:53
timotimo OK :) 22:54
i don't want to steal too many of your tuits
jnthn already said he could have a look at that branch, too
brrt :-) 22:55
jnthn (korean food)++
timotimo: oh no, I agreed to what? :)
Oh, the localref. I should have time tomorrow evening. 22:56
timotimo :D
cool
brrt just fixed my thinko WRT jitting objbody and stable references to objects in registers
so now we have a single repr op devirtualized
jnthn ah, cool :)
timotimo atpos_*
jnthn Does it make much difference? :)
timotimo didn't test yet
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
jnthn yeah
I may tweak array stuff to make it more safely jittable too :)
timotimo jnthn warned there may be a change to the layout of MVMArray in the future
brrt if we have the exprcomp then it'll be easier to for reprs to jit ops by creating an expression tree
timotimo <3
jnthn brrt: Indeed
brrt i had not considered that before 22:58
that solves something
timotimo no, it solves EVERYTHING
er, sorry, carry on
brrt :-D
i should sleep too
see you!
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. :)
But yes, sleep first. :) 22:59
brrt yes, thanks :-)
timotimo i'm glad he still answers to the Bart Signal whenever i'm in dire need of his help :) 23:00
jnthn :D 23:01
hoelzro: (remove interactive member of MVMIOOps) you should get away with that at this point

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!