[Coke] =-[p0 01:15
07:11 kjs_ joined
timotimo i don't know that emoticn 07:12
emoticon*
07:18 Ven joined 07:19 FROGGS joined 07:20 lizmat joined 07:27 zakharyas joined 07:43 dalek joined 07:46 FROGGS joined 07:53 kjs_ joined
timotimo how do we feel about the interp having checks for REPRs built-in vs the functions that get called from the interpreter doing REPR checks? 08:11
i can probably build a function "emit reprcheck" that throws an exception just like thet interpreter would 08:14
for the jit, that is
brrt, do you think it'd be terrible to implement lt_s, gt_s, le_s, ge_s and cmp_s as "append_call_c + append_primitive" and having the == 1/>= 0/== -1/<= 0/NOP part in emit.dasc with a comment saying "the actual comparison was already handled by a call to C"? 08:26
the terrible part being "there's an implementation of gt_s in the .dasc file that doesn't do anything with strings! wtf!" 08:27
i think that'd be okay 08:28
08:38 kjs_ joined 09:01 FROGGS[mobile] joined 09:02 FROGGS[mobile]2 joined, lizmat joined
dalek arVM: 667b7b5 | jnthn++ | src/ (3 files):
Ensure thread ID is available after termination.

This has never worked properly, but a recent change in join/GC meant that the Rakudo spectests uncovered it.		 09:28
arVM: fd1ed2e | jnthn++ | src/main.c:
Add MVM_CROSS_THREAD_WRITE_LOG to usage message.
 09:35
Heuristic branch merge: pushed 81 commits to MoarVM/x64-dynamic-registers by bdw 09:40
arVM: 227c556 | jnthn++ | src/instrument/crossthreadwrite.c:
Don't accidentally the newline to STDOUT.
09:42 brrt joined
brrt i'm somewhat cautiously optimistic i've fixed the RSP/R12 encoding issues 09:42
09:43 zakharyas joined
timotimo sounds good! :) 09:45
jnthn brrt++ # nice
x64 instruction encoding sounds...hairy
brrt it is
and brittle
actually, it'd be ok without this exception 09:46
timotimo in addition to gt_s and friends, i'll also add the sc related ops
brrt: how do you suggest it'd be easiest to handle ops that have a repr check + exception throw in their interp.c block?
brrt for some reason though, github doesn't seem to propagate my push
(do (when (ne (^repr_id obj) (const (&QUOTE MY_EXPECTED_REPR_ID) ptr_sz)) (^throw_adhoc (&MSG not the right repr))) (call (^repr_func blabla) etc) 09:48
yes, that's the world's worst LISP :-P 09:49
timotimo oh
i was thinking of the old jit at this point :)
dalek arVM: 1cf0479 | jnthn++ | src/core/interp.c:
Try to get PC on valid instruction in CTW logging.
timotimo unless of course you think the new jit will be up soon enough :D
brrt well, i hope at least 09:51
ok, clearly doesn't quite kick it yet 09:52
i'm not terribly surprised as it is quite brittle code
too bad, i was too eager yet 09:53
jnthn Ouch ouch ouch ouch damn 10:05
I just discovered where a bunch of our thready crashes come from 10:06
FROGGS ?
jnthn We have a race condition around following ->outer chains 10:07
FROGGS uhh
that would explain some of the error messages, yeah
jnthn And it just got more noticable
Because yesterday I fixed a code-gen bug that meant we takeclosure'd loads of things we should not have
timotimo oh! 10:08
jnthn Which meant the frames lived until the next GC run
Rather than dying immediately 10:09
And so hid the races
JimmyZ we have a 'takeclosure' roadmap on moarvm.org :P
jnthn JimmyZ: That's mostly about teaching spesh to understand it; this is something else
brrt ouch, that hurts 10:10
timotimo well, i'm glad i showed you the way to this sillyness in our codegen :)
JimmyZ oh, I thought it's about the api itself.
jnthn timotimo: Yes, that was a good hint and helped us get Text::CSV down to better than before we merged glr :)
timotimo yup <3 10:11
jnthn I'm glad to have this issue uncovered and caught nicely in the debugger, 'cus it will have been a source of much more occasional instability
But yeah, how to fix it is...interesting
Or how to fix it *well* is, anyway 10:12
ohh, I wonder if... 10:13
timotimo i wonder why 10:14
yesterday you told me 'bout the blue, blue sky
dalek arVM/even-moar-jit: 491c1c9 | brrt++ | src/jit/x64/tiles.dasc:
Offset is a 32 bit integer
arVM/even-moar-jit: e863e0d | brrt++ | 3rdparty/dynasm:
Update DynASM to deal with r12/rsp irregularity

RSP and R12 registers are encoded 'specially' because in legacy x86 RSP would have a special access mode.
timotimo oh, look, the push came through
brrt yeah
we still aren't fully correct though
but we at least don't SIGSEGV in a silly way 10:15
ok, we're not out of the woods yet 10:17
:-)
mov r8,QWORD PTR [rbp-0x30] 10:20
to the tune of the ting tings: that's not my code 10:21
jnthn
.oO( that code is totally over-r8-ed )
brrt i don't emit negative offsets, and certainly not from rbp 10:23
y does this happen to me :-(
gdb can tell fortunately
timotimo so another bit of wrong codegen, i suppose? 10:39
or ... code coding?
jnthn Darn, the crash vanishes under valgrind... :( 10:40
10:50 Ven joined
timotimo valgrind prevents the memory from being overwritten by bogus data? 10:50
jnthn Or slows things down too much to race 10:52
timotimo ah 10:54
yeah, that sounds likely, indeed
my jit addendae don't cause spectest fallout 11:13
jnthn Aha 11:15
The interesting race is actually in the invocation sequence it seems
timotimo rather than returning? interesting 11:16
jnthn Yeah, we read the outer to invoke with 11:17
But don't increment it at that point
Increment its refcount that is
That happens later
By which time it may already have been killed
Then we try to re-use it 11:18
dalek arVM: 9f140d8 | timotimo++ | src/ (3 files):
jit continuationreset and continuationcontrol

these ops have to be set "invokish" for this to work
jnthn Brining a dead frame back to life
dalek arVM: 9f038d4 | timotimo++ | src/jit/ (2 files):
jit string comparison ops
timotimo so how come the solution isn't to just put the increment a bit earlier?
jnthn Question is if we can without creating a data race 11:19
Well, without *retaining* it 11:20
timotimo mhm, we really don't want to go atomic or even worse take a lock for invocations 11:21
jnthn But making it rarer
Right :) 11:22
Anyway, now I understand what's going on, at least.
It explains quite a bit.
Anyway, lunch, and got a few other bits to do this afternoon. 11:23
Will have to ponder this one a bit
timotimo idly wonders about having bitwise reference counts rather than numeric 11:24
perhaps a little spinlock could be less than terrible 11:26
perhaps with a little spinlock we can also get rid of the atomic inc and dec for the refcount
huh, where'd my "skip unshift_n and push_n because they're wonky" change to? 11:29
go*
JimmyZ timotimo: demin.ws/blog/english/2012/05/05/at...ock-mutex/ 11:31
timotimo oh, wow 11:32
the mutex has so much overhead?
amazing
11:49 tadzik joined
dalek arVM: 00b3dfd | timotimo++ | src/jit/graph.c:
don't devirt push_n or unshift_n for now

because of a strange bug resulting in "expected num register"		 11:52
arVM: 0c250b1 | timotimo++ | src/jit/graph.c:
remove a solitary trailing whitespace
11:54 kjs_ joined
timotimo brrt got an idea what kind of speedup we can expect for not so tight loops from exprtree jit? 12:11
12:35 brrt joined
timotimo i only recall the very old estimate from hand crafted asm 12:48
but i also don't remember what the factor was 12:50
brrt no, i have no idea. hand crafted asm did really well. on a high level, i kind of know how we could get there
timotimo istr 6x?
brrt 5x versus the current jit, iirc
timotimo mhm 12:51
brrt but i cannot overemphasisze that we are really, really, really far from there
timotimo can we expect 2x as soon as the code gen runs?
you have seenbthe asm it generatesbalready
mhhh
if we do not regress, we can at least flip the switch on graph.c 12:52
brrt no, we can't expect 2x 12:53
we might expect 0.95x, more likely
timotimo when the rough code generation problems have gone, maybe i can look into implementing missing bits here or there
ugh
brrt hmmm
timotimo oj afk for a big bit
brrt i'm not sure this was a codegen bug after all
i see i do emit rbp-relative code
see you! 12:54
(i've though ahead on how to implement the optimizer)
fwiw, using lispy code fragments like i said earlier is not what i'm going to do 12:55
has any of you tried gdb mode within emacs? it works quite well actually 12:58
FROGGS I'm not an emacser...
brrt well, what do you use? 12:59
emacs is actually turning more IDE-like as you go along 13:00
if you want it, at least
FROGGS I use SciTE 13:03
I've seen lightning talks about emacs... though, I don't feel like changing my editor :o) 13:04
jnthn I keep meaning to give Visual Studio Code a try given it supports Perl 6 :) 13:05
brrt it what 13:31
visual studio code supports perl 6 ? :-o :-o
jnthn It claims to have syntax highlighting for Perl 6
brrt awesome 13:32
JimmyZ url? 13:35
found it
[Coke] url? I haven't found it. :) 13:55
JimmyZ blogs.perl.org/users/andrew_shitov/...ditor.html 13:59
[Coke] tries out visualstudio for os x... wonder if I can build moarvm here... 14:28
this feels a lot like atom. 14:29
jnthn I'm not surprised. ;)
It's based on Electron too iirc 14:30
tadzik everything HTML5 is the same :P
FROGGS I bet they use the Perl 6 syntax highlighting hoelzro++ did 14:31
JimmyZ adobe has a editor to, it is on github
[Coke] ... I am lost. jnthn, do you use the studio to build, or command line tools?
JimmyZ *too 14:32
jnthn [Coke]: command line tools
14:34 dalek joined
btyler_ hi folks. just want to check in before I go filing more PRs like this: github.com/MoarVM/MoarVM/pull/258 -- is this a useful thing, or would you rather I just file issues with crashing P6 snippets? 14:41
JimmyZ Didn't we fix it already? 14:43
btyler_ we fixed write,close 14:44
this is close,close and close,write
JimmyZ oh 14:45
btyler_: PRs are wellcome, but it'd be nice to have some test in roast too :P 14:47
14:48 dalek joined
btyler_ oh, cool, thanks for reminding me -- yes, that makes lots of sense 14:49
FROGGS jnthn: VSC is awesome! i.imgur.com/T7AcHpv.png
jnthn: it shows the modified line (compared to git) with a blue bar and the branch I am on (at the buttom) 14:50
jnthn FROGGS: Is it actually doing Perl 6 highlighting there or Perl 5? :)
[Coke] based on the snapshot, that's perl5 14:51
it would say "Perl 6" in the corner.
did seem to work on .p6 files, anyway. 14:52
FROGGS ohh
JimmyZ you need use v6! 14:53
FROGGS even when I select Perl 6, it gets colonpairs wrong for example 14:57
but it is okay 14:58
ohh nice, it also shows changed lines (compared to git) on the scrollbar
that's quite handy 14:59
hoelzro btyler_++ # fixes
dalek arVM: 8fd8663 | (Francois Perrad)++ | src/ (3 files):
fix indentation
 15:05
arVM: 383de34 | (Francois Perrad)++ | src/jit/graph.c:
remove useless &
arVM: 0607cb2 | (Francois Perrad)++ | src/6model/reprs/CUnion.c:
remove unless header file
arVM: ea3d8a1 | (Francois Perrad)++ | src/ (3 files):
include with angle

math.h & sys/wait.h are part of standard libraries
MoarVM: 9099796 | paultcochrane++ | build/Makefile.in: 15:09
MoarVM: Remove more config and generated files in distclean target
MoarVM:
MoarVM: As mentioned in GH #139, the `realclean` target doesn't clean everything up.
MoarVM: Actually, it seems that the `distclean` target is the one which is supposed
MoarVM: to clean up the configuration and generated files (at least in MoarVM).
MoarVM: This wasn't happening completely and the current commit removes all files
MoarVM: still needing to be cleaned.
MoarVM:
MoarVM: The file `src/jit/emit_posix_x64.c` is force-removed since it might not
MoarVM: exist on non-POSIX systems. The `config.log` and `config.status` files
MoarVM: within the atomic ops library are also removed, although they really should
MoarVM: 9b805c3 | (Ben Tyler)++ | src/io/asyncsocket.c:
MoarVM: Async sockets: handle close,close and close,write.
MoarVM:
MoarVM: This avoids a segfault in case of Perl 6 code like this:
MoarVM:
15:10 dalek joined 15:57 kjs__ joined 16:54 tadzik joined 17:25 tokuhiro_ joined 17:29 brrt joined 17:58 brrt joined 18:22 FROGGS joined 18:26 tokuhiro_ joined
FROGGS o/ 18:27
japhb o/ 18:30
timotimo o/ 18:33
brrt \o 19:06
i ++ the removal of src/jit/emit_posix_x64.c, which i also do in the even-moar-jit branch 19:07
so i suppose that's paultcochrane++ :-)
dalek Heuristic branch merge: pushed 22 commits to MoarVM/even-moar-jit by bdw 19:54
19:57 ggoebel joined 20:28 tokuhiro_ joined 22:23 tokuhiro_ joined 23:12 lizmat joined 23:39 dalek joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!