Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-12

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

All times shown according to UTC.

Time Nick Message
00:29 flaviusb joined #moarvm
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:25 domidumont joined #moarvm
05:29 domidumont joined #moarvm
05:53 domidumont joined #moarvm
06:25 brrt[irrsi] joined #moarvm
06:36 nwc10 good *, #moarvm
06:38 arnsholt o/
06:50 brrt[irrsi] good *, #moarvm
06:52 nwc10 "sent from my iphone^H^H^H^Hrc client" :-)
06:59 brrt[irrsi] :-P
06:59 brrt[irrsi] I decided to add it to signify that I'm not always looking at this one
07:00 brrt[irrsi] .... maybe there is an automated way to change my nick to 'idle' after not looking at it for a while
07:00 brrt[irrsi] or maybe I just shouldn't worry
07:02 arnsholt Irssi is scriptable with Perl
07:02 arnsholt I've never been able to find any useful documentation for it though
07:02 brrt[irrsi] hmm... erc is scriptable in emacs-lisp....
07:02 arnsholt But I wouldn't worry about it, TBH
07:03 * brrt[irrsi] ponders the tradeoff
07:03 arnsholt If people prod you and you don't reply, they know to try again later or leave a .tell
07:03 brrt[irrsi] but if i stay logged in on this box under 'brrt', then i can never reclaim my name if I lose access to it
07:04 arnsholt There is that
07:04 arnsholt What server is it on?
07:04 nwc10 8.20.57.5.in-addr.arpa domain name pointer proxy-gw-l.booking.com.
07:04 arnsholt I mean if it's hack, you can always get one of the sysadmins to kill the irssi session for you
07:05 nwc10 I'd guess "not the machine that owns the publicly visible IP"
07:05 arnsholt Speaking of, I should probably migrate my irssi session from the University servers to my Linode, now that I'm no longer at the University
08:04 brrt[irrsi] heh, I have had to migrate /all/ my e-mail and data from my university accounts last weekend
08:04 brrt[irrsi] I don't have an account on hack
08:04 brrt[irrsi] (have been meaning to)
08:26 arnsholt Yeah, I've had all my mail going to my GMail for ages now
08:26 arnsholt So I don't have to do that at least
08:43 jnthn morning, #moarvm
09:03 brrt[irrsi] morning jnthn
09:40 zakharyas joined #moarvm
09:58 brrt[work] joined #moarvm
10:35 dalek MoarVM: 5d45c56 | timotimo++ | src/6model/serialization.c:
10:35 dalek MoarVM: "missing deserialize repr func" gives debug_name now, too.
10:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5d45c5643f
11:03 TimToady joined #moarvm
11:08 dalek joined #moarvm
11:13 dalek MoarVM: 5370a30 | timotimo++ | src/6model/serialization.c:
11:13 dalek MoarVM: debug_name for missing serialize function, too!
11:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5370a30d69
11:25 brrt[work] timotimo++
11:26 brrt[work] I found out why I need a list of retired live ranges
11:26 brrt[work] not all live ranges I create are eventually assigned a register, becasue some of them are split and spilled
11:27 brrt[work] a spilled live range is split into a number of 'atomic' live ranges, and it is these live ranges which are assigned registers, not the original one
11:29 brrt[work] so the spilled live range never makes it to the retired list, but the 'fragments' do
11:30 brrt[work] interesting fallout is that we want to iterate that retired list (in the register /assignment/ step) in first-definition order, *just as we do the original worklist*, and that hence I'd either need to sort the thing, or maintain it as a heap
11:31 brrt[work] minor efficiency choice: do we maintain it as a heap while adding retired live ranges (complexity, O(n log n)), or do we heapify it afterwards (complexity: O(n))
11:32 brrt[work] of course, picking all n items from the heap is itself O(n log n), so who cares
15:00 dalek MoarVM: 224b5e8 | jnthn++ | src/core/oplist:
15:00 dalek MoarVM: Mark 3 ops deprecated.
15:00 dalek MoarVM:
15:00 dalek MoarVM: We'll remove them, plus a forth long-deprecated one, in the next
15:00 dalek MoarVM: release.
15:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/224b5e8083
15:04 japhb .oO( We supported FORTH ops? )
15:05 jnthn d'oh :)
15:07 mst jnthn: DROP AND ROLL while you still can
15:09 * japhb momentarily considers side tracking brrt by convincing him to rewrite his assembler in FORTH, but decides that's perhaps just a bit too evil ...
15:12 dalek MoarVM: e121a0a | jnthn++ | / (8 files):
15:12 dalek MoarVM: Implement indexingoptimized op.
15:12 dalek MoarVM:
15:12 dalek MoarVM: If the string it is given as an operand is already free of strands,
15:12 dalek MoarVM: simply returns that string. Otherwise, produces a flat string with
15:12 dalek MoarVM: the same graphemes. This takes on the "optimize for regex engine"
15:12 dalek MoarVM: role that flattenropes used to have.
15:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e121a0a71e
15:26 dalek MoarVM: eceb429 | jnthn++ | src/jit/graph.c:
15:26 dalek MoarVM: JIT the new indexingoptimized op.
15:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eceb4296ab
15:29 JimmyZ jnthn: looks like miss MVM_free(orig) in e121a0a71e
15:30 jnthn No?
15:30 jnthn The point is to *not* do it in place
15:31 jnthn So the original string lives on
15:31 jnthn And its buffer is still reachable
15:34 JimmyZ ah, mis-read the code since there is a orig there :)
15:34 jnthn :)
15:35 jnthn Yeah, the in-place was a really bad idea in hindsight :(
15:35 jnthn As it gets us in a total mess concurrency wise
15:36 * jnthn has seen a number of backtraces now that were a result of use-after-free involving MVM_string_flattenropes
15:40 domidumont joined #moarvm
15:54 FROGGS joined #moarvm
16:04 FROGGS domidumont: the comparison of the module debug output revealed nothing...
16:04 FROGGS domidumont: so I'll check the dyncall build this evening like you proposed
16:16 brrt[work] oh, forth, that is a great idea :-P
16:16 timotimo it's a cool language
16:16 mst FORTH LOVE? IF HONK THEN
16:19 brrt[work] jnthn: I'm not sure, but I think this will mean that with flat strings operations like get-char-at-pos can be inlined?
16:20 * brrt[work] should work on having simpler grammar in sentences
16:20 jnthn brrt[work]: Yes...well, that was always the intention but things changing in-place torpedoed it
16:21 jnthn Need to think about how I get rid of the rest of it, though.
16:36 travis-ci joined #moarvm
16:36 travis-ci MoarVM build errored. Jonathan Worthington 'JIT the new indexingoptimized op.'
16:36 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/167089009 https://github.com/MoarVM/MoarVM/compare/e121a0a71eda...eceb4296abb4
16:36 travis-ci left #moarvm
16:38 domidumont FROGGS: ok. I've added a backtrace in the github ticket
16:38 domidumont FROGGS: but it won't help much.
17:40 travis-ci joined #moarvm
17:40 travis-ci MoarVM build errored. Jonathan Worthington 'Implement indexingoptimized op.
17:40 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/167084677 https://github.com/MoarVM/MoarVM/compare/224b5e80834c...e121a0a71eda
17:40 travis-ci left #moarvm
17:42 timotimo Found /tmp/moar/bin/moar version 2016.09-45-ge121a0a, which is too old.
17:42 timotimo ^- this caused the travis build to fail
17:45 FROGGS domidumont: how did you get that backtrace?
17:45 FROGGS I'm somehow unable to do that
17:47 FROGGS I get it to hang, but that's all
17:52 domidumont FROGGS: see the link at the end of the comment.
17:53 FROGGS domidumont: I did, and I followed the instructions...
17:53 FROGGS but it keeps hanging
17:53 FROGGS (until I kill -9)
17:54 domidumont FROGGS: when it's hung, run a kill -TRAP this will trigger a core dump
17:54 domidumont don't forget "ulimit -c unlimited" before running moar
17:55 domidumont then the core looks like qemu_moar_20161012-133329_14379.core
17:56 FROGGS # ps ax | grep moar
17:56 FROGGS 8351 pts/12   Sl+    0:09 /usr/bin/qemu-aarch64-static /home/nqp/install/bin/moar --execname=./perl6-gdb-m --libpath=/home/nqp/install/share/nqp/lib --libpath=. /home/rakudo/perl6.moarvm t/04-nativecall/02-simple-args.t
17:56 FROGGS # kill -TRAP 8351
17:56 FROGGS nothing happens
17:58 domidumont Hmm, I'm running moar in a chroot. Once in the chroot, I don't need to call qemu to run moar
17:59 FROGGS that output is from running ps from outside of qemu
17:59 FROGGS 'cause I dont have /proc mounted in qemu
18:00 domidumont forget that I said: here the output of ps on my system: root     14379 27555 50 13:32 pts/8    00:00:12 /usr/bin/qemu-aarch64-static /usr/bin/moar --execname=./perl6-m --libpath=/usr/share/nqp/lib --libpath=/usr/lib/perl
18:00 domidumont 6 --libpath=. perl6.moarvm t/04-nativecall/02-simple-args.t
18:00 geekosaur does qemu do something special with SIGTRAP?
18:01 domidumont kill -TRAP 14379  in another terminal (also in the chroot) -> I get a core dump
18:01 domidumont did you run ulimit in the shell that runs moar ?
18:02 domidumont gotta go, need to cook for the kids ...
18:03 FROGGS yes, did run ulimit
18:03 FROGGS and I just have run: kill -TRAP 8351
18:03 FROGGS nothing happens
18:15 domidumont here's what I get when I run "kill -TRAP": qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
18:15 domidumont Trace/breakpoint trap
18:16 domidumont may be: make sure that /proc /sys or /dev are shared between host and chroot (bind mount). I use schroot that take care of this
18:16 domidumont gotta run again, kid is back
18:21 FROGGS sharing proc and/or sys seems to help
18:25 FROGGS weird
18:26 FROGGS when running in gdb I cant do anything
18:26 geekosaur pid inside the jail vs. outside it
18:26 geekosaur and gdb also uses /proc, so.
18:26 FROGGS when running without gdb, I can pause the process when sending -STOP
18:26 FROGGS -TRAP does nothing
18:27 FROGGS geekosaur: the pids are the same
18:34 FROGGS huh, -QUIT worked
18:43 FROGGS but the dump is rather useless
18:56 FROGGS domidumont: without knowing any more details I'd say the newer libuv version is the problem
18:56 FROGGS https://github.com/libuv/libuv/compare/5467299450ecf61635657557b6e01aaaf6c3fdf4...d989902ac658b4323a4f4020446e6f4dc449e25c
18:56 FROGGS a lot of changes that could be at fault
18:57 FROGGS though, bisecting this is not a very fun task
19:06 domidumont interesting. I've install libuv1-dbg and the backtrace shows more stuff -> posted on github ticket
19:07 domidumont FROGGS: ^^ some MVM symbols do show up
19:08 FROGGS ohh nice
19:09 FROGGS I posted mine... weird that they are different
19:10 FROGGS I guess yours makes more sense
19:11 domidumont I test with package generated by debian packaging and installed the package containing the debug symbols.
19:12 FROGGS my dump is from the debian libuv package also
19:12 FROGGS since the libuv that's shipped with moarvm doesnt make it hang
19:14 FROGGS I'm going to bed a little bit early today... gnight
19:17 Ven_ joined #moarvm
19:40 ilbot3 joined #moarvm
19:40 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
20:35 Ven_ joined #moarvm
20:54 Ven_ joined #moarvm
21:13 BinGOs_ joined #moarvm
21:15 d4l3k_ joined #moarvm
21:18 BinGOs joined #moarvm
21:18 JimmyZ_ joined #moarvm
21:25 flaviusb joined #moarvm
22:31 dalek MoarVM: 736364c | timotimo++ | src/strings/ops.c:
22:31 dalek MoarVM: dogbert17++ found this memleak in ord_basechar_at
22:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/736364c02a
22:31 timotimo it took a long time from writing the fix to actually committing & pushing because there was food, and then there was forgetting

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