Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-09-14

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:33 domidumont joined #moarvm
05:52 domidumont joined #moarvm
06:48 dalek MoarVM/even-moar-jit: 2d9434e | brrt++ | docs/jit/register-allocator.org:
06:48 dalek MoarVM/even-moar-jit: Map out more of the cruft that needs removal
06:48 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2d9434e83a
06:48 brrt joined #moarvm
07:48 zakharyas joined #moarvm
08:58 jnthn morning, #moarvm
09:07 moritz \o jnthn
09:10 brrt \p
09:11 timotimo \q
09:11 brrt haha
09:17 timotimo that's my pony tail
09:17 brrt then in my case it should be \u
09:18 brrt (beard and balding)
09:18 timotimo aaw
09:21 brrt would rather not, but can't be helped
09:23 jnthn Hm, I suspect a day or so before the relaese isn't the best time to do the Unicode 9 bump :)
09:24 brrt no… i suspect  not
09:24 brrt (the everlasting drum of the release march)
09:28 jnthn :)
09:28 jnthn It'd probably go fine, I'm just a little risk-averse :)
09:29 jnthn I suspect I'll do some bug fixes this morning, and then continue doing I/O stuffs this afternoon :)
09:30 brrt ugh, i'd check if the IO-Socket-Async thing was better now, and haven't yet
09:34 konobi oh... did i mention that there's a portable version of libumem available which gives lots of fun insight, debugging, guards and analysis of memory management (as an LD_PRELOAD or shared lib)
09:35 brrt i think you did not
09:36 konobi i found it very useful when working on nodejs and stopping myself from kicking myself in the ass with memory leaks and faulty references/pointers, etc.
09:36 konobi especially with the stack being as dynamic as it is in async code
10:24 dalek MoarVM: ef129c4 | jnthn++ | src/core/threadcontext.c:
10:24 dalek MoarVM: Fix missing finalization queue cleanup.
10:24 dalek MoarVM:
10:24 dalek MoarVM: Only a small leak, but it adds to the clutter when looking at valgrind
10:24 dalek MoarVM: leak check output.
10:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ef129c42ca
10:50 travis-ci joined #moarvm
10:50 travis-ci MoarVM build passed. Jonathan Worthington 'Fix missing finalization queue cleanup.
10:50 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/159836447 https://github.com/MoarVM/MoarVM/compare/7b6c0925597b...ef129c42cad8
10:50 travis-ci left #moarvm
10:51 * brrt wonders if it is time to switch from MVM_JIT_EXPR_ENABLE to MVM_JIT_EXPR_DISABLE
10:52 jnthn Not 2 days before release ;)
10:52 brrt haha
10:52 jnthn I guess it passes spectest etc though?
10:52 brrt well, even-moar-jit isn't merges
10:52 brrt merged yet
10:52 jnthn ah
10:52 brrt afaik yes
10:53 brrt or at least 'as well as master'
10:53 jnthn :)
10:53 brrt but that is in part because it does only very, very tiny fragments yet
10:53 jnthn I guess on the branch it makes sense...how far are we from that being mergable?
10:53 brrt that.. is an excellent question, and i'm glad you asked
10:54 brrt my goal for 'mergeable' has been so far: 'will not explode if people without deep internal knowledge add new templates and tiles to it'
10:54 nwc10 brrt: what branch(es) should I test with ASAN?
10:54 brrt and includes 'can represent the full range of MoarVM opcodes as templates' and 'can compile all templates that are currently implemented'
10:54 nwc10 (not that this is likely to show up all JIT issues. valgrind is more likely to spot others)
10:55 brrt nwc10: if you'd test even-moar-jit with MVM_JIT_EXPR_ENABLE=1 set, then I'd be very grateful :-)
10:56 brrt so, with that said…. the missing piece that i'm slowly assembling is a regional register allocator (as in, can deal with IF, CALL and friends)
10:56 brrt the other bit is that I really have to add a few more security pieces to handle all annotations correctly
10:57 brrt it is about a weeks worth of work to make it mergeable, but at my current pace, that will take at least another month
10:57 brrt perhaps two
10:58 brrt after that, mountains of work left, but less of it 'core'
10:58 jnthn Curious. https://rt.perl.org/Ticket/Display.html?id=129161 seems to leak because SCs never get kicked out of the weak hash...
10:58 jnthn (that is, they go unclaimed)
10:59 * brrt is not sure if he has valgrind on this machine
11:00 * brrt has not
11:02 konobi libumem you can run as a preload, so you don't have the emulation overhead of valgrind to contend with
11:04 timotimo kind of like asan, or is umem more than that?
11:05 konobi it's specifically for memory operations
11:05 timotimo oh, so it also handles accesses? regular writes and reads?
11:05 timotimo how can a preload do that o_O
11:05 konobi libc
11:07 konobi that's also why libfaketime is so damn handy
11:07 brrt i think it is solaris specific though?
11:07 konobi nope, OmniTI made a portable version years ago
11:08 brrt cool
11:08 konobi the docs refer to solaris, but it's all actually pretty agnostic platform wise
11:09 konobi so with ldpreload you can use a bunch of environment variables to enabled/disable/set/get functionality
11:09 timotimo brrt: "can represent the full range of moarvm opcodes as templates" just means all features that you might need in order to implement each op is there?
11:10 brrt yes, and things won't break when doing so
11:10 timotimo OK
11:10 timotimo you don't blog often enough for me to know what the status towards "can compile all templates that are currently implemented" is :P
11:11 nine brrt: so once even-moar-jit is merged, it's mostly a matter of going through profiles and dumps and find opcodes that prevent JITing and implement their support?
11:11 brrt timotimo: that is a very fair point
11:11 brrt nine: yes
11:11 brrt that is the intention
11:11 brrt has been the intention for over a year :-$
11:13 timotimo ;)
11:18 konobi so a moarvm opcode is a class with instances, that need functionality... i see a role! mwuahahaha
11:18 timotimo i'm not sure that's accurate
11:19 konobi well, representable as one =0)
11:19 timotimo though tbh, many opcodes come with a check "does this object have the right REPR?" and/or "is it initialized?"
11:19 konobi rw values
11:20 jnthn lunch &
11:20 timotimo we really only have two opcodes that have an rw value
11:20 konobi fun for debugging via meta reflection
11:21 konobi anywhos... i'm down the MOP rabbit hole again ^_^
11:21 timotimo OK :)
11:24 brrt timotimo: actually rw values are treated as read-only values
11:24 brrt because simpler
11:25 brrt or, just as 'read' values
11:25 brrt and they are handled simply by passing the address rather than the value
11:25 brrt ....
11:25 brrt hang on
11:25 brrt hmm
11:26 brrt no, that doesn't have any ugly repercussions, actually
11:26 konobi is there a pre-existing mop library for C?
11:26 nine brrt: looking forward to that. Sounds like fun :)
11:27 timotimo well, in the JIT maybe, but code gen and spesh have to handle it differently
11:27 * timotimo packs up for driving home
11:27 * brrt hopes to deliver it soonish
11:27 timotimo yay
11:27 brrt konobi: i have no idea what you could mean with a MOP library for C :-)
11:27 brrt but suggests that soonish for me may be longer that for you
11:28 timotimo there's gobject
11:28 timotimo that's pretty much a mop library
11:30 konobi yup
11:31 konobi a language really only needs 3 features to support a mop... and the 3rd one is usually fudgeable (and sometimes the first two too)
12:15 * jnthn returns from lunch and continues leak hunting
12:17 konobi brrt: ah yes... this is what got me working with libumem outside of solaris again... http://dtrace.org/blogs/ahl/2004/07/13/number-11-of-20-libumem/
12:18 brrt konobi: thanks for the link :-)
12:18 konobi there's practically no overhead (i know of places where it's used in production by default) so it's really handy for running with a harness to catch errors early
12:20 jnthn Well dammit, turns out at some point we ended up with EVAL leaking again... :(
12:21 brrt :-(
12:21 brrt i'd venture to suggest that volunteer projects such as MoarVM benefit disproportionally from automated regression tests
12:21 konobi https://www.usenix.org/legacy/event/usenix01/bonwick.html
12:22 brrt but that it is, on the other hand, rather time consuming to set them up
12:22 * jnthn wonders how to write a test for this particular case
12:22 konobi i actually use bats (TAP for bash) often for more esoteric things
12:23 jnthn I didn't last time I fixed it.
12:24 konobi brrt: in the libumem case, it's nice and easy... install on machine, set env vars, consume output after tests are run
12:26 brrt no, it seems like a hard test
12:35 jnthn Seems I fixed it anyway
12:35 jnthn A lot faster than last time, because this time I didn't take the diversion of writing a heap profiler :P
12:35 jnthn moar-ha++
12:36 brrt hehe :-)
12:36 brrt that is a cool tool, for sure
12:36 jnthn The fix is a one line patch
12:36 nwc10 we owe your beer fridge. If only there was some
12:36 nwc10 oh wait
12:36 nwc10 http://news.perlfoundation.org/2016/09/perl-6-performance-and-reliabi-2.html
12:36 jnthn Right :)
12:36 nwc10 the bit marked "Leave a comment"
12:40 konobi brrt: when loaded as preload, just run as normal... you get stats and info in generated artifact files (contents, location, etc. all settable with env vars)
12:41 brrt konobi: I'm fairly sure it is cool. But at this point, I can't really do anything with it, because I'm not working on moarvm atm :-)
12:41 brrt i'll be sure to read the documentation you've sent me
12:41 brrt but haven't yet :-)
12:42 dalek MoarVM: 4938b65 | jnthn++ | src/core/bytecode.c:
12:42 dalek MoarVM: Mark SC used in bytecode loading as claimed.
12:42 dalek MoarVM:
12:42 dalek MoarVM: Otherwise, it might be considered unclaimed and so go uncollected,
12:42 dalek MoarVM: thus leading to things like EVAL leaking memory.
12:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4938b65065
12:44 konobi cool
15:59 domidumont joined #moarvm
16:41 Ven_ joined #moarvm
17:52 dalek MoarVM: 2eedba8 | jnthn++ | src/6model/ (2 files):
17:52 dalek MoarVM: Fix a-bit-too-few error in multi cache.
17:52 dalek MoarVM:
17:52 dalek MoarVM: The indexes we store for args are indexes into the args buffer (which
17:52 dalek MoarVM: includes names) rather than the callsite flags, meaning that they can
17:52 dalek MoarVM: be up to twice as long. Fixes a bug where we could fail to find some
17:52 dalek MoarVM: entries when caching callsites with many named args, resulting in the
17:52 dalek MoarVM: same entries being put into the cache again and again.
17:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2eedba88d2
17:55 Ven_ joined #moarvm
18:09 Ven_ joined #moarvm
18:24 FROGGS joined #moarvm
18:38 Ven_ joined #moarvm
18:54 travis-ci joined #moarvm
18:54 travis-ci MoarVM build errored. Jonathan Worthington 'Fix a-bit-too-few error in multi cache.
18:54 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/159951368 https://github.com/MoarVM/MoarVM/compare/4938b6506592...2eedba88d2b0
18:54 travis-ci left #moarvm
19:33 jnthn bah, hung during a git pull
19:34 geekosaur git doesnt handle network glitches well
19:35 geekosaur (this is actually a problem for me as the upstream NAT router has far too few NAT slots; at times it loses NAT table entries in under 30 seconds...)
19:36 mst geekosaur: ssh proxy via your own box?
19:37 geekosaur I redirect some stuff over a hotspot currently and just retry for anything I don't want to blow extra money for
20:52 Zoffix left #moarvm

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