hoelzro jnthn: is there anything special I have to do to be able to remove it? when I try to build rakudo after removing it, I get a segfault =/ 00:02
so I removed linenoise from MoarVM, but now when I try to use Linenoise.pm (which I just created), linenoise's read() returns EAGAIN; is there anything Moar may be doing that would be interfering with standard iput? 01:27
*input
dalek arVM/no-moar-linenoise: e30ab31 | hoelzro++ | / (13 files):
Remove linenoise/readline

Now that NativeCall is included with Rakudo, instead of having linenoise/readline functionality be bundled in as a VM-level op, let's create a NativeCall-based module for this functionality		 01:52
02:10 zakharyas joined
hoelzro I'm guessing standard input is made non-blocking by MoarVM? 02:17
that would explain what I'm seeing with linenoise
04:40 vendethiel joined 05:21 vendethiel joined 06:26 Peter_R joined 06:32 pyrimidine joined 07:28 zakharyas joined 07:53 FROGGS joined 07:56 Ven joined 08:18 FROGGS joined 08:50 FROGGS joined 09:20 lizmat joined 09:24 kjs_ joined 09:25 Ven joined 10:30 vendethiel joined 10:34 Peter_R joined 11:19 donaldh joined 11:30 Ven joined 11:38 Ven joined 12:15 zakharyas joined
hoelzro does MoarVM set STDIN to non-blocking by default? 12:39
nwc10 hoelzro: I fear that only jnthn really knows that, and he's $dayjob teaching on site 12:44
hoelzro I figured as much 12:46
FROGGS hoelzro: we set it to blocking by default in MVM_file_get_stdstream 12:48
hoelzro I see
12:48 Ven_ joined
hoelzro I'm just thinking about how that will work when using NativeCall with libraries that expect stdin to be in blocking mode 12:49
nwc10 presumably they would break in the same way as anyone else calling them from code using an event loop 12:52
that's sort of "how do other VMs/thingies cope with this?" 12:53
hoelzro nwc10: I'm not sure, but I'm thinking that Node.JS may be the only other environment that does this 12:54
it's just surprising is all
took me a bit of head scratching before I figured out why linenoise was constantly returning 0 length strings =) 12:55
FROGGS :o)
12:56 Ven joined 13:03 Ven joined
timotimo i'll continue work on devirtualizing repr ops now :) 13:07
Ven timotimo++ 13:10
13:27 brrt joined
brrt \o 13:27
(the Bart sign, i'm flattered :-D) 13:28
timotimo :D 13:29
wait 'til i show you your new Bart Mobile
13:30 rurban joined
brrt but yeah, timotimo++ for devirtualizing repr ops 13:32
that's awesome work
timotimo :) 13:33
thank you
so brrt 13:35
should all _n related ops have their own piece of emit code? 13:36
brrt :-)
what are the n related ops?
timotimo because of VAL_F and RV_F?
brrt oh
nwc10 I can't answer that directly, but there do seem to have been a series of easy to make, hard to spot systematic errors with floating point calling conventions 13:37
timotimo because we had that differently a whole bunch of time
brrt ehm.. well, yeah, unless you use checks afterwards to modify them, or conditionals like (op == foo_n ? RV_N : RV_I)
timotimo fair enough
but it'll always be needed, eh?
brrt but yes, that's true
nwc10 so anything that makes it harder to screw up, without making it harder to do thing generally, is a good idea
brrt floating points are basically always passed either on stack or in FPR, never in GPR 13:38
timotimo so much cleanup to do ...
brrt (on x86 and x86-64)
the only thing that is really ambiguous as far as i know is passing structs
and returning them
timotimo this damned huge switch statement ... so hard to have a good overview 13:56
brrt very true 13:58
you can.... i'm not against making large tables 13:59
in a header file for example
and read from there
timotimo a header table? 14:00
dalek arVM/jit_devirtualize_reprops: e04e158 | timotimo++ | src/jit/graph.c:
shuffle all ops around, make sure we have all repr ops

and only repr ops. at least in the consume_reprop function.		 14:28
nwc10 timotimo: that commit isn't complete (or otherwise not working) 14:30
src/jit/graph.c:808:65: error: ‘MVM_JIT_RV_STR’ undeclared (first use in this function)
brrt strs and objs are pointers
so you should use MVM_JIT_RV_PTR (iirc) 14:31
the rationale for using a ptr return type is that they will have different sizes per arch unlike the integer types which are defined as 64 bits 14:34
timotimo nwc10: i just noticed, too, thanks :) 14:37
i'll have a fixup commit coming soon
dalek arVM/jit_devirtualize_reprops: 878b0b1 | timotimo++ | src/jit/graph.c:
RV_STR doesn't exist ...
 14:39
arVM/jit_devirtualize_reprops: 588810e | timotimo++ | src/jit/graph.c:
devirtualize bindkey and bindpos ops
brrt oh, timotimo, btw, if you want to use a type definition in dynasm you have to enter a .type declaration 14:41
timotimo i don't understand why, but i understand that i'll have to do it from now on :) 14:42
which op to devirtualize next?
damn, i'm having trouble deciding 14:47
dalek arVM/jit_devirtualize_reprops: 487eb38 | timotimo++ | src/jit/graph.c:
since _o and _s can be handled the same way, we do that.
 14:49
brrt it's so that dynasm can recognise your reference as a type declaration
rather than a variable
dynasm doesn't parse C :-) 14:50
timotimo oh, i see 14:58
srsly, what op do i do next? 15:00
brrt hint; add a MVM_jit_log(tc, "emit repr op %s", op->name), and then count the number of these lines 15:02
timotimo my code is borked, though 15:06
dalek arVM/jit_devirtualize_reprops: f08bfad | timotimo++ | src/jit/graph.c:
actually hook up bindkey/pos ops, now this is broken :(
 15:08
15:09 FROGGS joined
dalek arVM/jit_devirtualize_reprops: ff82dee | timotimo++ | src/jit/graph.c:
more wrongness fixes
 15:14
timotimo why is it segfaulting now :( 15:16
brrt lets see 15:17
timotimo i'll go grocery shopping in the mean time 15:20
thanks for looking! :)
nwc10 timotimo: valgrind won't say more than this: 15:37
==21675== Invalid read of size 8
==21675== at 0x4F656A3: MVM_interp_run (interp.c:2763)
==21675== by 0x503A320: MVM_vm_run_file (moar.c:210)
==21675== by 0x401250: main (main.c:189)
so straight out NULL pointer dereference. No prior undefined behaviour
timotimo oh wait 15:45
it seems like i've been taking the value of the register 15:46
dalek arVM/jit_devirtualize_reprops: bcb2317 | timotimo++ | src/jit/graph.c:
fix thinko about register addr vs value
 15:52
timotimo should i wait until post release to merge jit_devirtualize_reprops into master? 15:55
brrt: how do you feel about allowing %d or something like that in log filenames/env vars that'd be filled in with the pid? 16:01
FROGGS timotimo: yes, please wait 16:03
brrt oh, i was just about to point you to the reg_addr thinko :-)
timotimo thanks :) 16:04
brrt i'm ok with that, or any other filename
i had imagined the jit dump files were called MVMJitCode-$filename.bin
but that was not the case yet 16:05
timotimo they do have the function name in them, though
brrt by the way, bindpos always passed the register directly, never the floating-point-containing-the-register 16:06
it's an approximation. it is quite difficult to correlate an mvmframe to a filename or function
timotimo yeah
oh, so the _F is still wrong? 16:07
brrt yes
you don't need it in this case
timotimo 1689 emit repr op elems 16:08
291 emit repr op getattr_s
these are top 1 and 2
for compiling the setting
brrt when in doubt check src/core/interp.c ;-)
timotimo 4041 repr op push_i couldn't be devirtualized: type unknown
1827 repr op atkey_o couldn't be devirtualized: type unknown
941 repr op getattr_i couldn't be devirtualized: type unknown
these are interesting; though getattr with a known type will often be turned into a sp_p6o... op earlier on 16:09
brrt i'm going to have dinner 16:17
see you :-)
dalek arVM/jit_devirtualize_reprops: 4b38c6c | brrt++ | src/jit/graph.c:
bindpos and bindkey take an MVMRegister argument

Thus these are always passed as a regular value, never as a float.		 16:21
timotimo 2114 emitted an atpos_* or atkey_* via jgb_consume_reprop 16:31
1689 emitted a elems via jgb_consume_reprop
201 emitted a bindpos_* or bindkey_* via jgb_consume_reprop
dalek arVM/jit_devirtualize_reprops: 9d61133 | timotimo++ | src/jit/graph.c:
implement MVM_op_elems for devirtualization
timotimo seems to give no measurable difference on my int @a; my int $i; while $i < 10000000 { @a[$i] = 1; $i = $i + 1 } 16:44
hm 16:48
maybe it does
it's quite a noisy "benchmark"
ghhhhhhhhhhhhhhhrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrm 16:49
(that was cat)
for that benchmark, we have a few ops we could devirtualize (if they were implemented): 16:53
44 emit repr op getattr_o
22 emit repr op push_o
the rest is <10
(however, sadly that doesn't show usage distribution) 16:54
well, the frame that the code spends ~100% of time in already has all potential ops devirtualized 16:55
so that's something
and now i'll take the rest of the evening off (but not most of the night) 16:56
zpämmmmbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbnmmmmmmmmmmmmmmmmmmmmmmmmm000000000000000000000000000000 16:57
jnthn wonders if the cat will take the evening off too :P 16:58
timotimo (also, i let the cat roam free all over my laptop keyboard)
he looks pretty pleased with himself, that cat
~o/ 16:59
(hair blowing in the wind)
17:03 donaldh joined 17:10 FROGGS joined 17:14 kjs_ joined 18:39 kjs_ joined 18:52 vendethiel joined
timotimo can someone perhaps run benchmarks with and without that branch? maybe not the whole p6bench suite 19:01
nwc10 can't, but ASAN didn't barf on it
19:53 mj41 joined 20:34 colomon joined
nwc10 jnthn: if you want MOAR news, I think it's reasonable to suggest that "we're building on big endian again (tested on PPC32 and PPC64)" 21:00
dalek arVM: 194de10 | jnthn++ | docs/ChangeLog:
ChangeLog for 2015.03.
 21:04
jnthn nwc10: Yes, that's worth a "headline" mention I guess :)
dalek arVM: 7623778 | jnthn++ | VERSION:
Bump VERSION.
 21:08
arVM: 327fc12 | jnthn++ | ports/macports/Portfile:
Bump version in Portfile.
arVM/cpp2: 75e5909 | FROGGS++ | Configure.pl:
use CPPFLAGS if set, baby-gnu++
 21:14
MoarVM/cpp2: 309561c | (Daniel Dehennin)++ | Configure.pl:
MoarVM/cpp2: Use CPPFLAGS is @cflags instead of @ldflags
21:14 dalek joined 21:15 dalek joined 21:20 kjs_ joined
nebuchadnezzar arf, just see my typo :-/ 21:47
FROGGS :o) 21:49
21:49 colomon joined
japhb OOC, does bumping version in the Portfile get picked up automatically, or does someone end up having to ping the macports team? 21:51
jnthn www.moarvm.org/releases/MoarVM-2015.03.tar.gz 21:54
japhb: According to the release guide, I now have to make [Coke]++ ping the macports team. 21:55
japhb Heh
FROGGS jnthn: builds fine on linux 21:57
jnthn yay 21:58
jnthn checked that too, but is glad to have a second conf :) 21:59
FROGGS :o)
nebuchadnezzar ok, I'll update the debian packaging soon 22:11
dalek href="https://moarvm.org:">moarvm.org: 5696465 | jnthn++ | / (3 files):
Update website for 2015.03 release.
 22:16
timotimo .o( but the new data isn't on the website yet? ) 23:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!