Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-03

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

All times shown according to UTC.

Time Nick Message
00:37 jnap joined #moarvm
01:54 FROGGS_ joined #moarvm
03:37 cognominal joined #moarvm
06:39 ingy joined #moarvm
06:44 FROGGS_ joined #moarvm
06:52 zakharyas joined #moarvm
07:04 woolfy left #moarvm
08:37 masak what's origin/osr ?
08:37 nwc10 osr is "On Stack Replacement"
08:37 nwc10 does that start to answer your question?
08:37 masak it seems to have branched our from origin/moar-jit at some point, but then been left behind.
08:37 * masak tries to rebase it locally
08:37 nwc10 ah OK. that part I can't answer
08:38 masak it rebases cleanly!
08:38 nwc10 in that, the facetious answer to your question was "it's a branch in git", and it wasn't clear what your actual question was
08:38 moritz http://wingolog.org/archives/2011/06/20/on-stack-replacement-in-v8
08:38 nwc10 cool.
08:39 nwc10 but I'm a bit surprised that it (seems to) branch from moar-jit, as that is brrt, whereas OSR is jnthn
08:39 masak aye.
08:39 moritz it seems OSR is a non-trivial topic
08:39 masak there'e one commit on origin/osr, and it's jnthn's
08:40 masak oh, origin/inline has been merged!?
08:41 masak is there a reason to keep the branch after that?
08:41 masak I guess so -- jnthn would probably have removed it otherwise.
08:49 FROGGS no, we love our branches, so we let them rest after merging...
08:57 jnthn OSR got merged too; I'm sure I deleted the origin one...
08:58 jnthn Yeah, my git branch -a doesn't show it.
08:58 jnthn masak: Needeth you to prune? :)
08:58 moritz maybe maska need to fetch with --prune ?
08:58 jnthn oh...I didn't think of doing it like that
08:58 * jnthn always git remote prune origin
08:59 nwc10 I count 18 remote branches
08:59 jnthn inline I kept around in case the merge had ot be reverted 'cus we found some terrible bug.
08:59 moritz also: git config --global fetch.prune true
09:00 jnthn But that hasn't happened, so... :)
09:00 masak ooh, fetch --prune :)
09:00 masak jnthn, moritz: thank you.
09:00 masak I did need that.
09:00 jnthn 'tis gone.
09:00 moritz gone to meet its maker
09:00 moritz erm...
09:01 masak jnthn: what about origin/inline ?
09:01 jnthn ?
09:01 jnthn I'd already killed the local one
09:01 jnthn A week ago
09:01 jnthn I just killed origin
09:01 jnthn C:\consulting\MoarVM>git push origin :inline
09:01 jnthn To git@github.com:MoarVM/MoarVM.git - [deleted]         inline
09:01 masak oh!
09:01 masak jnthn++
09:02 masak FROGGS: what about origin/loop_labels ? :)
09:02 FROGGS this can go :o)
09:06 dalek MoarVM/moar-jit: af60ecc | (Bart Wiegmans)++ | src/spesh/deopt.c:
09:06 dalek MoarVM/moar-jit: Take frame modification and taget finding out of deopt
09:06 dalek MoarVM/moar-jit:
09:06 dalek MoarVM/moar-jit: Currently deopt relies on finding the target by
09:06 dalek MoarVM/moar-jit: the current bytecode offset of the instruction that
09:06 dalek MoarVM/moar-jit: caused the deopt. This won't do for JIT, because it
09:06 dalek MoarVM/moar-jit: doesn't have this notion. So we need a version of
09:06 dalek MoarVM/moar-jit: deopt_one that is passed the deopt target directly.
09:06 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/af60ecc681
09:07 brrt joined #moarvm
09:08 avar joined #moarvm
09:10 brrt hmm.. it occurs to me that i'll have to pass the 'optimised offset' as well as the 'target offset' to deopt because of inline
09:17 sergot o/
09:23 brrt \o sergot
09:27 masak FROGGS: "this can go" as in "delete that branch!" ?
09:29 jnthn brrt: oh? That sounds like it should be avoidable...
09:30 brrt i don't think so, but you know the code better than i do
09:30 brrt uninline uses both offsets
09:31 FROGGS masak: delete that branch!
09:31 * masak does so
09:31 FROGGS masak++
09:32 masak done.
09:34 nwc10 16 more to go
09:39 jnthn Nooo! Don't delete moar-jit :P
09:39 jnthn Or master :P
09:39 jnthn origin/gen2-frames is probably dead
09:39 nwc10 16 + master
09:39 nwc10 of which how many are current?
09:40 jnthn Probably few are current; some may contain interesting experiments.
09:42 * brrt still has a copy of moar-jit :-)
09:49 * jnthn too :)
09:50 brrt rebless calls deopt all
09:50 brrt hmmm
09:50 brrt ok
09:53 jnthn Hm, deopt_all is trickier, yes.
09:55 brrt it is - fortunately - not really relevant right now
09:55 jnthn *nod*
09:55 brrt also, i suspect it can be 'kickstarted' with the right deopt offseet :-)
09:56 brrt offseat
09:59 woosley left #moarvm
09:59 woosley joined #moarvm
10:00 jnthn ontable?
10:27 timotimo are they ontable? what does it mean to be onted?
10:37 * brrt feels like he has missed important part of the conversation
10:38 jnthn brrt: I was just punning on the typo "offseat", then timotimo punned my pun :P
10:39 brrt i see
10:39 brrt :-)
10:57 zakharyas joined #moarvm
11:10 brrt hmm... weird-bugs yay
11:15 * brrt feels as if the newly minted guards don't work
11:17 jnthn I've got thyme to glance a diff, if you like...
11:17 brrt it's a big diff
11:17 brrt more importantly
11:17 brrt it probably hangs of the 'autoviv' ops too
11:17 jnthn ah
11:18 brrt it's probably best to 'shut these off' for now
11:18 brrt and, so it what
11:18 brrt so it was
11:19 nwc10 thyme to glance at a diff and give sage advice?
11:20 jnthn Could be anise thing to do.
11:20 jnthn But maybe brrt++ can keep the bugs at bay without my help...
11:20 nwc10 it helps new contributors cumin to this project
11:21 brrt i appreciate the help greatly
11:21 brrt but you'd be looking at nothing i'm afraid :-)
11:21 nwc10 and such feedback ensures existing contributors aren't just resting on their laurels
11:22 nwc10 [that one feels like it somehwat fails technically as a pun, given it's real laurel]
11:24 dalek MoarVM: e86162f | (Tobias Leich)++ | src/6model/reprs/CArray.c:
11:24 dalek MoarVM: fix typo in CArray.elems error message
11:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e86162fe3d
11:28 brrt ok, the lexical autoviv check seems to work
11:30 brrt or not hmm :-(
11:35 brrt ok, unitialized value is non-null, but doesn't seem to be VMNull either
11:37 jnthn It is a sane pointer-like value?
11:38 brrt seems-to-be
11:38 brrt oh, this is actually an uninitialized value, great
11:38 nwc10 valgrind?
11:38 brrt (not-actually, i mean)
11:39 brrt i can try valgrind, yes :-)
11:40 brrt but looks sane
11:41 * jnthn wonders how valgrind's instrumentation + a JIT compiler works out together...
11:41 brrt i have no idea, really
11:42 * brrt is off for a walk
11:43 brrt do you happen to know if uninitialized values point to NQPMu or something like that?
11:43 jnthn Only if there's something there to make them do so
11:43 brrt i'll try it out
11:43 jnthn (as in, the lexical is bound to it in code)
11:44 jnthn (you'd see a bindlex instruction if it's happening explicitly)
11:44 jnthn Just a wild thought: you're not missing a deference and so confusing the register pointer with the value in the register?
11:44 brrt no, i don't think so
11:45 brrt basically, rdx holds the value of the environment 'register'
11:45 brrt which is then copied directly to the local register
11:46 brrt and this works for integers, but i haven't checked for objects, because
11:46 brrt object access caused a sp_guardconc or sp_guardtype to be emitted, and i hadn't done deopt yet
11:49 brrt how can i get the type name of an object in nqp
11:50 jnthn $obj.HOW.name($obj)
11:51 brrt thanks :-)
11:52 brrt yes, it's NQPMu
11:52 brrt that explains
11:52 brrt ok, then i'm confident committing for now
11:58 dalek MoarVM/moar-jit: 30be083 | (Bart Wiegmans)++ | / (12 files):
11:58 dalek MoarVM/moar-jit: Limited support for spesh guards.
11:58 dalek MoarVM/moar-jit:
11:58 dalek MoarVM/moar-jit: Because a bug in the 'autoviv' variants of
11:58 dalek MoarVM/moar-jit: sp_p6oget_o is visible only now, I disabled these ops
11:58 dalek MoarVM/moar-jit: so that they could be tested independently.
11:58 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/30be083f33
11:59 brrt left #moarvm
12:35 jnap joined #moarvm
12:36 JimmyZ joined #moarvm
12:38 JimmyZ Hello, looks like moarvm is broken on windows, since `./try` is not supported on windows, And I dont' know get it work.
12:38 FROGGS JimmyZ: what is './try' ?
12:39 JimmyZ probe.pm
12:40 jnthn JimmyZ: huh, since when? It configures/builds fine for me...
12:40 brrt joined #moarvm
12:40 * brrt back
12:41 JimmyZ I dont' know, it built for me too.  and I saw it commited 5 months ago. I don't know why it dosn't build after serval weeks.
12:44 JimmyZ It may be  my problem , I run it under VS2012 X64 cross tool
12:46 JimmyZ yeah, it works under in Developer command prompt for vs2012.
13:23 * brrt af
13:23 brrt k
13:23 brrt left #moarvm
13:24 timotimo do we eliminate multiple bindlex that happen directly in a row, like "first bind NQPMu, then bind 1"? ISTR our optimizer does that nowadays
13:25 jnthn I think in NQP if there is a bind right at the declaration site it skips emitting a default value for the lexical...maybe.
13:26 jnthn Doing it at VM level is way harder than just spotting one bindlex after another in the CFG
13:26 jnthn What if an inner frame asks for the value between the two points?
13:29 timotimo fair enough
13:33 teodozjan joined #moarvm
14:08 brrt joined #moarvm
14:13 brrt hmmm...
14:13 brrt st should not be zero for a 'real' object, should it?
14:14 jnthn No.
14:14 timotimo i thought every object has an stable
14:14 timotimo in order to be an object in the first place
14:14 jnthn If you get a zeroed ST then you're looking at bogus memory
14:15 brrt ok
14:15 brrt good to know
14:15 timotimo at least it's a clear sign
14:15 jnthn Which *may* mean a GC bug, but that's highly unlikely these days.
14:15 brrt i'm not assuming a gc bug
14:16 jnthn Yeah, most of the time I hit such a thing these days, it's nothing to do with GC.
14:16 jnthn Just a bad pointer
14:17 brrt what is more annoying is that i don't actually know which frame this is :-(
14:17 jnthn tc->cur_frame->static_info->body.[name|cuuid]
14:17 brrt good point
14:17 FROGGS jnthn: but now you can debug it in Perl 6 using OpaquePointer :P
14:18 jnthn Oh,a nd then find the data buffer point and look at it in...the memory window...but I guess your debugger isn't Visual Studio :)
14:18 FROGGS I guess our OpaquePointer can be like sun.jna.Pointer but just done right
14:19 brrt my debugger is gdb and can in fact do these things :-)
14:19 jnthn oh, I'm very sure it can, I just don't know how to ask it to :)
14:19 brrt i'm not very sure, either, but i'll manage
14:20 brrt ok, pos is fine, it seems
14:49 brrt on the other hand... it' possible my check_wb stuff doesn't work :-(
14:53 ggoebel111116 joined #moarvm
14:55 brrt no, check_wb is never even hit
15:02 ggoebel111116 joined #moarvm
15:06 brrt ok, this is odd
15:06 brrt sp_guardtype seems to be triggered for the wrong local
15:07 brrt oh... hmmm
15:17 ggoebel111116 joined #moarvm
15:23 vendethiel joined #moarvm
15:24 timotimo wait, with an OpaquePointer REPR'd object you can have the address of any MVM* object and access that?
15:26 FROGGS yes
15:26 FROGGS you can dump the memory of an p6opaque to a floppy disk if you know its size in memory
15:29 FROGGS like: nativecast(CArray[uint8], OpaquePointer.new( $bar.WHERE )); "out".spurt: CArray[^$something]
15:30 FROGGS well, except for the stupid mistakes I did there
15:31 * brrt is off for dinner (and crying)
15:31 brrt stupid bugs
15:31 FROGGS ahh, your code will probably explode when $bar.WHERE is outdated before the nativecast call finishes
15:31 * FROGGS hugs brrt
15:31 brrt :-)
15:31 brrt left #moarvm
15:31 FROGGS just to hold you back so somebody can steal me your food :P
15:36 FROGGS[mobile] joined #moarvm
15:47 timotimo %)
15:49 FROGGS[mobile] but I guess it is quite possible to make an awesome JNIish thing
15:49 vendethiel joined #moarvm
15:50 FROGGS[mobile] an even better one perhaps
15:50 FROGGS[mobile] because Java just sucks
15:53 vendethiel joined #moarvm
15:59 timotimo :|
16:00 timotimo perl6 will be the best language to interface with C on the JVM ...
16:01 jnthn dinner, beer &
16:09 rurban Better than Clojure? Doubt it. https://github.com/bagucode/clj-native
16:12 timotimo we don't have all these weird parens! :P
17:06 vendethiel joined #moarvm
17:06 FROGGS[mobile] rurban: will look at that for sure :o)
17:30 rurban no parens but even weirder chars, all these $@%#{}[] curses
17:40 FROGGS joined #moarvm
17:43 FROGGS rurban: I have problems reading that clojure code... and it is hard to see what it can do what we can't
17:43 rurban :)
17:43 FROGGS but either way, when we can satisfy [Sno], we might have the most awesome native interface :o)
17:44 rurban I have made a very old FFI comparison table once. dylan came out as best FFI
17:44 rurban http://autocad.xarch.at/lisp/ffis.html
17:46 rurban But Visual Basic and Smalltalk were also excellent
17:47 FROGGS hmmm, looks like I have to dig way deeper into that topi
17:47 FROGGS topic*
18:07 FROGGS looks like returning CArray[my_struct] from a NativeCall sub is borken
18:26 FROGGS why does it call ten times CArray[my_struct].at_pos(0) when I only access it once from P6?
18:28 FROGGS hmmm
18:32 timotimo jnthn commented on that once when lizmat got surprised how often a proxy's fetch would be called
18:40 FROGGS at least it has a cache, so it hits the cache nine times from ten
18:56 FROGGS shouldn't this behave the same?
18:56 FROGGS sub foo() returns MyStruct         is native { * }
18:56 FROGGS sub foo() returns CArray[MyStruct] is native { * }
18:57 FROGGS hmmm, perhaps not
18:58 moritz CArray[MyStruct] would be a pointer to MyStruct
18:59 FROGGS MyStruct** then
18:59 FROGGS that would explain it
19:02 FROGGS we really need a sizeof() for CStructs and friends
19:05 brrt joined #moarvm
19:10 timotimo and alignof, too, please?
19:14 FROGGS eww, can of worms, I tell 'ya
19:20 cognominal https://gist.github.com/cognominal/f1cc48cab3ca8bed4257  # already pasted on #perl6
19:47 carlin joined #moarvm
19:55 avar joined #moarvm
19:58 brrt ok, i can establish that the 'normal version' of sp_p6oget do in fact work normally
19:59 timotimo the non-vivifying variant?
20:02 brrt yes
20:03 dalek MoarVM/moar-jit: e39348f | (Bart Wiegmans)++ | / (5 files):
20:03 dalek MoarVM/moar-jit: Establish that sp_p6oget_i actually works.
20:03 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e39348ffbe
20:03 brrt why the vivifying variant doesn't work, i have no idea
20:15 brrt hmm
20:15 brrt the guard isn't quite alright, either
20:16 brrt ok, so maybe it's a guard problem
20:16 brrt phew :-)
20:19 brrt so the problem seems to be in sp_guardconc
20:19 woolfy joined #moarvm
20:19 lizmat joined #moarvm
20:22 brrt if the problem is in sp_guardconc, that'd be awesome
20:28 brrt but of course, it isn't that simple
20:33 timotimo .o( the guards are all right )
20:37 brrt the guards are not ok, not yet :-)
20:37 brrt left #moarvm
20:43 * jnthn back
20:43 timotimo hey jnthn
20:46 jnthn grr...router started doing its "I'm going to drop half the things" act again
20:48 dalek joined #moarvm
22:14 btyler joined #moarvm

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