Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-06

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

All times shown according to UTC.

Time Nick Message
00:16 timotimo bindlex         lex(idx=7,outers=0,items),   r8(8)
00:16 timotimo getlex           r12(7), lex(idx=7,outers=0,items)
00:16 timotimo i don't even >_>
00:26 timotimo i thought we had something in place that inserts logs to see if things have changed since they got bound or something like that?
00:26 timotimo and we're supposed to improve handling of lexicals somehow?
00:27 timotimo doesn't seem so
00:29 timotimo the getlex_known will only fire for getlexstatic and getlexperinvtype (if spesh'd on invocant)
00:29 timotimo so that won't do anything here
00:47 vendethiel joined #moarvm
01:32 timotimo jnthn: do you think i can add something to the profiler such that we'd see native subs appear in the results, too?
01:32 timotimo i'm not actually sure whether or not the code that does the native call setup and dispatch will get hit by the profiler code gen ... but now that i actually think about it, i see no reason why not
01:39 vendethiel joined #moarvm
01:54 timotimo this isn't really hot code, but an acceptable example for a failure to eliminate a sink check: https://gist.github.com/timo/3d56aa47f53e43e7a500
01:55 timotimo ^- notice especially how the predecessor list of bb 3 contains bb 3 itself and if that wasn't the case, we should've probably been able to remove the sink check
01:56 timotimo (this is based on a local patch that changes a single line: it turns the $!handled attribute of Failure to be int rather than Any - gets us rid of a getattr + vivification and assign and should have gotten us to an implementation of method defined that doesn't have a sink check at all ...)
02:04 vendethiel joined #moarvm
02:59 vendethiel joined #moarvm
03:32 vendethiel joined #moarvm
05:06 sivoais joined #moarvm
06:35 FROGGS joined #moarvm
06:51 zakharyas joined #moarvm
07:22 brrt joined #moarvm
07:23 brrt *ahem* back
07:29 FROGGS hi brrt
07:29 brrt ohai!
07:29 FROGGS I did not understand what you said to me about dynasm
07:30 brrt long time ago you added a patch to choose a system dynasm for building moarvm
07:30 brrt i myself have once added the feature to add a system lua for using dynasm
07:30 brrt neither features have a purpose
07:31 brrt minilua which we ship is good enough for compiling dynasm, which is the only thing we ever do with it
07:31 FROGGS ahh, that --has-dynasm probably happened when working with daxim++ on opensuse packages
07:31 brrt dynasm should be our own because we've patched it :-)
07:31 FROGGS I see
07:32 brrt and the --lua feature works poorly together with the 'ensure minilua is compiled' rule
07:34 brrt so... they have to go
07:35 brrt (i noticed this all because i got a SEGV in dynasm. it turned out to be from not recompiling the .dasc files after changing dynasm)
07:40 brrt for the record, we don't ship the minilua tool, or the dynasm
07:40 brrt they're purely build-time dependencies
07:41 FROGGS then we should get rid of the said options
07:43 brrt patch coming up :-)
07:43 FROGGS brrt++
07:55 dalek MoarVM/even-moar-jit: ff95f73 | brrt++ | / (2 files):
07:55 dalek MoarVM/even-moar-jit: Building .dasc files depends on dynasm version
07:55 dalek MoarVM/even-moar-jit:
07:55 dalek MoarVM/even-moar-jit: Because I've patched dynasm to support extended register
07:55 dalek MoarVM/even-moar-jit: addressing, c files generated with an old version of dynasm
07:55 dalek MoarVM/even-moar-jit: are not compatible with the header of the new version. This is
07:55 dalek MoarVM/even-moar-jit: fix by adding a dependency from dynasm-generated c file to the
07:55 dalek MoarVM/even-moar-jit: dynasm scripts, and from the corresponding object file to the
07:55 dalek MoarVM/even-moar-jit: dynasm headers.
07:55 dalek MoarVM/even-moar-jit:
07:55 dalek MoarVM/even-moar-jit: At the same time, I've removed the --lua and --has-dynasm options
07:55 dalek MoarVM/even-moar-jit: from the configuration. The --lua option doesn't work well with
07:55 dalek MoarVM/even-moar-jit: the minilua-building rule, and the --has-dynasm option isn't very
07:55 dalek MoarVM/even-moar-jit: useful because our dynasm is now patched (and thus nonstandard).
08:29 brrt hmmm
08:29 brrt i have another question on which i'd like some advice
08:30 brrt i have implemented a simple visitor for the JIT tree
08:30 brrt i'm wondering if a): i want to have the visitor function control ascend/descend operations
08:31 brrt and i'm wondering b): if i want to resolve multiple-node-entries during walks or in the visitor
08:31 brrt two sides of the same coin, really
08:32 brrt a code generator that is being 'walked' over the tree can of course keep it's own bookkeeping on whether we've seen certain nodes before
08:32 vendethiel joined #moarvm
08:33 brrt if it can control the decision to ascend/descend, that means it can limit 'double walks' over the same tree
08:33 brrt (i'm indeed not really talking about trees anymore)
08:34 brrt on the other hand, are double walks so expensive that we should care? i'm skeptic
08:35 brrt does mean we may have superlinear walking costs in a bad case; e.g. suppose the first n/2 nodes are used by the second n/2 nodes; we'd have O(n/2*n/2) = O(n^2) walking cost
08:35 brrt kind of want to avoid that?
08:52 brrt of course, why not do both
09:07 brrt bugs bugs bugs
09:07 FROGGS O.o
09:13 brrt code is always so much better when it's never run
09:13 FROGGS :D
09:13 * FROGGS .oO( Never touch a sleeping system... )
09:15 brrt my greatest scare so far was yesterday evening when all of the sudden perl6 crashed in the dasm_put function
09:16 brrt that happened to be the 'dasc files isn't recompiled when dynasm scripts change' issue
09:18 brrt (btw, dnf really is dramatically faster than yum)
09:22 brrt note to self
09:22 brrt when iterating over a linked list, be sure to transition to the next pointer
09:27 FROGGS :P
09:38 brrt hmmm
09:39 brrt something up with the roots
09:39 brrt y u no correct
09:51 brrt (because you didn't copy them)
10:30 brrt damnit, why do we get latin capital letter l in the output :-(
10:30 FROGGS why not?
10:35 brrt well
10:35 brrt its an odd name for an opcode
10:41 FROGGS true
10:42 FROGGS bbiab
11:08 brrt ugh, many difficult
11:11 FROGGS joined #moarvm
11:36 brrt (of course it's difficult if you make mistakes. you dumbass)
11:37 FROGGS *g*
11:38 FROGGS don't make mistakes then, it is pretty simple :o)
11:45 dalek MoarVM/even-moar-jit: 4a6511f | brrt++ | / (4 files):
11:45 dalek MoarVM/even-moar-jit: Dump tree to inspect it.
11:45 dalek MoarVM/even-moar-jit:
11:45 dalek MoarVM/even-moar-jit: This uncovered so many bugs.
11:45 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4a6511f7f8
11:45 brrt the cool thing is, *it really works*
12:05 brrt (holy redundant set, batman)
12:06 dalek MoarVM/even-moar-jit: 009d9e5 | brrt++ | src/jit/expr (3 files):
12:06 dalek MoarVM/even-moar-jit: Minor improvements in tree generation
12:06 dalek MoarVM/even-moar-jit:
12:06 dalek MoarVM/even-moar-jit: Don't store right after a load; skip no_op, phi nodes
12:06 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/009d9e5e2e
12:07 brrt i... think i need some kind of macro facility in the tree-expression-compiler script
12:07 brrt otherwise this will get unwieldy very fast
12:07 brrt oh, there's an error in there, too
12:10 dalek MoarVM/even-moar-jit: 58e9936 | brrt++ | src/jit/expr (2 files):
12:10 dalek MoarVM/even-moar-jit: Minor fix of exprlist
12:10 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/58e9936833
12:11 brrt ooh, more core dumps
12:13 brrt hmm, never mind :-)
12:17 timotimo oh, things are moving forward? :D
12:18 timotimo can you show off some example dumps of the jit tree? :)
12:20 brrt yes
12:21 brrt it's the simplest thing possible, but here it is
12:21 brrt https://gist.github.com/bdw/80b52a7b7aaf967c2e03
12:21 timotimo does that come from a hand-crafted MAST tree?
12:22 timotimo like when you first built the very first JIT?
12:24 brrt no, just from the nqp source
12:25 brrt it's just an empty set
12:25 brrt (instruction)
12:25 timotimo oh lord, my favourite instruction :)
12:29 brrt the cage cleaning i was refering to implies removing the JitGraphBuilder
12:29 brrt no reason why the graph couldn't be the live structure
12:30 jnthn Afternoon, #moarvm
12:30 brrt \o jnthn
12:30 brrt still in kiev?
12:30 jnthn aye
12:30 jnthn hiding in air-conditioned apartment
12:31 rurban joined #moarvm
12:31 brrt :-)
12:32 FROGGS hi jnthn
12:32 jnthn o/ FROGGS
12:32 FROGGS I've seen some shaped array commits have landed?
12:32 FROGGS ohh, and you've blogged...
12:32 FROGGS need to read that soonish
12:33 jnthn Where on earth did checked_free_null come from
12:33 jnthn C's free function is happy enough to get a NULL pointer
12:34 brrt joined #moarvm
12:34 brrt JimmyZ made that patch. it replaced a free with a real null check, so if that was wrong it was wrong before :-)
12:34 brrt bbl
12:34 jnthn Yes, I meant that if (foo) free(foo); is equivalent to free(foo);
12:35 jnthn 'cus free already checked
12:35 jnthn *checks
12:36 timotimo ohai jnthn
12:39 JimmyZ really? so we don't need  MVM_checked_free_null at all?
12:40 JimmyZ just MVM_free_null
12:41 jnthn Um, just MVM_free(foo); as far as I'm concerned
12:41 jnthn In the REPRs anyway
12:42 jnthn There's very few places where correctness requires you to actually NULL it
12:42 jnthn Some people might once have said it aids debugging
12:42 jnthn But with tools like valgrind and ASAN it actually hurts debugging to NULL freed pointers.
12:43 jnthn (If you never expect to look at them again)
12:44 JimmyZ ok, so we can change many  MVM_checked_free_null to MVM_free ?
12:45 jnthn I'd say so
12:46 JimmyZ ok , I will do it. and remove MVM_checked_free_null(which is about 2 years old)
12:59 jnthn Righty, back to multi-dim stuff...
13:00 nwc10 jnthn: "afternoon"? - the coffee in this apartment isn't quite as good as the aircon?
13:02 jnthn nwc10: Well, also attempted some tourism and found some lunch.
13:03 jnthn It's just too hot outside to feel like doing much, alas...
13:04 nwc10 holiday suffers, MoarVM wins?
13:04 jnthn Maybe
13:05 jnthn Though last couple of days, and somewhat today, the allergy stuff gunked my ears up again some I've been feeling dizzy, which is crappy for doing anythhing...
13:15 timotimo that sucks :(
13:20 dalek MoarVM: cba9b92 | jnthn++ | src/6model/reprs/MultiDimArray.c:
13:20 dalek MoarVM: Implement cloning multi-dim arrays.
13:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cba9b92360
13:48 dalek MoarVM: 53468a9 | jnthn++ | src/ (3 files):
13:48 dalek MoarVM: Fill out remaining multi-dim array ops.
13:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/53468a905d
13:50 jnthn Seems there's just the serialization bits left.
13:52 jnthn Then I've gotta move on up to the Perl 6 level bits...
14:15 dalek joined #moarvm
14:27 dalek MoarVM: 647df11 | jnthn++ | src/6model/reprs/MultiDimArray.c:
14:27 dalek MoarVM: Implement serialize/deserialize of MultiDimArray.
14:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/647df11103
14:31 jnthn Yays.
14:41 FROGGS \o/
14:41 jnthn Decided to switch to RTs until dinner. :)
14:42 timotimo jnthn: +/- on teaching the profiler about nativecallinvoke?
14:42 jnthn Hope to work on the Perl 6 bits of multi-dim array stuff in the coming days
14:42 jnthn timotimo: What can we teach it? :)
14:42 jnthn I mean, +1 if you've got some concrete idea that gives us useful info ;)
14:42 timotimo AFAIK it doesn't measure time spent inside native routines at all
14:43 jnthn Ah, not as spearate routines,now
14:43 jnthn *no
14:43 timotimo and native routines don't show up in the profiler at all, right?
14:43 jnthn Aye
14:43 timotimo i mean, they don't have their own item with entries/exclusive/inclusive time etc
14:43 jnthn yeah, there's room for improvement and I can see it'd be nice to have :)
14:43 jnthn Correct, we don't do anything special with them yet
14:44 timotimo i'll have a look at how it'd be done and maybe implement it :)
14:45 jnthn My first idea would be to fake a call node in the profiler for it
14:45 jnthn call graph node, that is
14:46 timotimo that's what i think, too. i'd need something clever for the ->sf, though
14:46 timotimo i mean, i could potentially generate a fake staticframe for every native function we encounter
14:46 jnthn Oh, I'd NULL that
14:47 jnthn And maybe have a MVMString *native_name or char *native_name, whichever is most readily to hand
14:47 timotimo mhm
14:48 jnthn I suspect faking up a static frame will get fragile
14:48 timotimo the MVMNativeCallBody doesn't actually store the name of the target any more, just the entry point
14:48 timotimo i suspect so, too
14:49 jnthn Hm...
14:49 jnthn You could I guess keep the name around
15:02 timotimo well, we also have the name in the frame where we do the call in order to set things up
17:02 FROGGS joined #moarvm
17:25 zakharyas joined #moarvm
18:00 brrt joined #moarvm
18:03 brrt \o
18:04 brrt folks.. does it make any sense for me to make a macro facility in the expression tree compiler program?
18:05 brrt why? because we have tons of repeated expressions
18:08 FROGGS I can't answer any of your questions :o(
18:08 FROGGS I'd like to, but I can't
18:16 brrt hmm
18:17 brrt hmmmmhmmm
18:18 dalek MoarVM/even-moar-jit: c470b65 | brrt++ | / (2 files):
18:18 dalek MoarVM/even-moar-jit: Very minor fix (but a SEGV nevertheless)
18:18 dalek MoarVM/even-moar-jit:
18:18 dalek MoarVM/even-moar-jit: An MVMOpInfo.opcode is unsigned short (MVMuint16); this caused
18:18 dalek MoarVM/even-moar-jit: some problems with an extension opcode which was interpreted
18:18 dalek MoarVM/even-moar-jit: negative.
18:18 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c470b65d99
18:19 brrt my point is, in dynasm i've written tons of little helper macro's to e.g. get strings from the compunit
18:19 brrt i find that s-exps get rather unwieldy after a point, especially in the level of detail i have to manage
18:20 brrt and immensely error-prone
18:23 brrt and.. i just think it'd be a lot less error prone to use fragments that are known to be good
18:23 brrt macros
18:24 brrt maybe there is something you can help me with
18:24 brrt what sigil to give to my macro's
18:24 brrt i'm thinking either * or ^
18:24 brrt i like ^, 'on an upper level'
18:28 brrt (i've already constricted $ for parameters and & for c-level macro invocations (and sizeof and offsetof)
18:29 brrt % and @ would give the wrong idea, # is already for comments
18:29 brrt also > would be possible
18:34 brrt hell, lots of characters in ascii
18:35 * brrt afk
18:37 FROGGS ohh, we are inventing a new language here?
19:03 colomon joined #moarvm
19:39 Peter_R joined #moarvm
19:49 ggoebel joined #moarvm
19:56 brrt joined #moarvm
19:57 brrt actually, somewhat like it; i have written a tree template preprocessor
19:57 brrt it's really a (very tiny) compiler
20:00 brrt these templates end up to form the expression trees
20:01 brrt the thing is, now i have the problem of writing lots and lots of those tree templates
20:01 brrt many of those are quite complex
20:02 brrt they're written in s-exp, so you can probably understand that they become unwieldy
20:52 synbot6 joined #moarvm
22:54 TEttinger joined #moarvm

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