00:29 flaviusb joined 01:48 ilbot3 joined 05:25 domidumont joined 05:29 domidumont joined 05:53 domidumont joined 06:25 brrt[irrsi] joined
nwc10 good *, #moarvm 06:36
arnsholt o/ 06:38
brrt[irrsi] good *, #moarvm 06:50
nwc10 "sent from my iphone^H^H^H^Hrc client" :-) 06:52
brrt[irrsi] :-P 06:59
I decided to add it to signify that I'm not always looking at this one
.... maybe there is an automated way to change my nick to 'idle' after not looking at it for a while 07:00
or maybe I just shouldn't worry
arnsholt Irssi is scriptable with Perl 07:02
I've never been able to find any useful documentation for it though
brrt[irrsi] hmm... erc is scriptable in emacs-lisp....
arnsholt But I wouldn't worry about it, TBH
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
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
arnsholt There is that 07:04
What server is it on?
nwc10 8.20.57.5.in-addr.arpa domain name pointer proxy-gw-l.booking.com.
arnsholt I mean if it's hack, you can always get one of the sysadmins to kill the irssi session for you
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
brrt[irrsi] heh, I have had to migrate /all/ my e-mail and data from my university accounts last weekend 08:04
I don't have an account on hack
(have been meaning to)
arnsholt Yeah, I've had all my mail going to my GMail for ages now 08:26
So I don't have to do that at least
jnthn morning, #moarvm 08:43
brrt[irrsi] morning jnthn 09:03
09:40 zakharyas joined 09:58 brrt[work] joined
dalek arVM: 5d45c56 | timotimo++ | src/6model/serialization.c:
"missing deserialize repr func" gives debug_name now, too.
 10:35
11:03 TimToady joined 11:08 dalek joined
dalek arVM: 5370a30 | timotimo++ | src/6model/serialization.c:
debug_name for missing serialize function, too!
 11:13
brrt[work] timotimo++ 11:25
I found out why I need a list of retired live ranges 11:26
not all live ranges I create are eventually assigned a register, becasue some of them are split and spilled
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:27
so the spilled live range never makes it to the retired list, but the 'fragments' do 11:29
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:30
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:31
of course, picking all n items from the heap is itself O(n log n), so who cares 11:32
dalek arVM: 224b5e8 | jnthn++ | src/core/oplist:
Mark 3 ops deprecated.

We'll remove them, plus a forth long-deprecated one, in the next release.		 15:00
japhb
.oO( We supported FORTH ops? )
 15:04
jnthn d'oh :) 15:05
mst jnthn: DROP AND ROLL while you still can 15:07
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:09
dalek arVM: e121a0a | jnthn++ | / (8 files):
Implement indexingoptimized op.

If the string it is given as an operand is already free of strands, simply returns that string. Otherwise, produces a flat string with the same graphemes. This takes on the "optimize for regex engine" role that flattenropes used to have.		 15:12
arVM: eceb429 | jnthn++ | src/jit/graph.c:
JIT the new indexingoptimized op.
 15:26
JimmyZ jnthn: looks like miss MVM_free(orig) in e121a0a71e 15:29
jnthn No? 15:30
The point is to *not* do it in place
So the original string lives on 15:31
And its buffer is still reachable
JimmyZ ah, mis-read the code since there is a orig there :) 15:34
jnthn :)
Yeah, the in-place was a really bad idea in hindsight :( 15:35
As it gets us in a total mess concurrency wise
jnthn has seen a number of backtraces now that were a result of use-after-free involving MVM_string_flattenropes 15:36
15:40 domidumont joined 15:54 FROGGS joined
FROGGS domidumont: the comparison of the module debug output revealed nothing... 16:04
domidumont: so I'll check the dyncall build this evening like you proposed
brrt[work] oh, forth, that is a great idea :-P 16:16
timotimo it's a cool language
mst FORTH LOVE? IF HONK THEN
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:19
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
Need to think about how I get rid of the rest of it, though. 16:21
16:36 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'JIT the new indexingoptimized op.' 16:36
travis-ci.org/MoarVM/MoarVM/builds/167089009 github.com/MoarVM/MoarVM/compare/e...eb4296abb4
16:36 travis-ci left
domidumont FROGGS: ok. I've added a backtrace in the github ticket 16:38
FROGGS: but it won't help much.
17:40 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Implement indexingoptimized op. 17:40
travis-ci.org/MoarVM/MoarVM/builds/167084677 github.com/MoarVM/MoarVM/compare/2...21a0a71eda
17:40 travis-ci left
timotimo Found /tmp/moar/bin/moar version 2016.09-45-ge121a0a, which is too old. 17:42
^- this caused the travis build to fail
FROGGS domidumont: how did you get that backtrace? 17:45
I'm somehow unable to do that
I get it to hang, but that's all 17:47
domidumont FROGGS: see the link at the end of the comment. 17:52
FROGGS domidumont: I did, and I followed the instructions... 17:53
but it keeps hanging
(until I kill -9)
domidumont FROGGS: when it's hung, run a kill -TRAP this will trigger a core dump 17:54
don't forget "ulimit -c unlimited" before running moar
then the core looks like qemu_moar_20161012-133329_14379.core 17:55
FROGGS # ps ax | grep moar 17:56
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
# kill -TRAP 8351
nothing happens
domidumont Hmm, I'm running moar in a chroot. Once in the chroot, I don't need to call qemu to run moar 17:58
FROGGS that output is from running ps from outside of qemu 17:59
'cause I dont have /proc mounted in qemu
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
6 --libpath=. perl6.moarvm t/04-nativecall/02-simple-args.t
geekosaur does qemu do something special with SIGTRAP?
domidumont kill -TRAP 14379 in another terminal (also in the chroot) -> I get a core dump 18:01
did you run ulimit in the shell that runs moar ?
gotta go, need to cook for the kids ... 18:02
FROGGS yes, did run ulimit 18:03
and I just have run: kill -TRAP 8351
nothing happens
domidumont here's what I get when I run "kill -TRAP": qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped 18:15
Trace/breakpoint trap
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
gotta run again, kid is back
FROGGS sharing proc and/or sys seems to help 18:21
weird 18:25
when running in gdb I cant do anything 18:26
geekosaur pid inside the jail vs. outside it
and gdb also uses /proc, so.
FROGGS when running without gdb, I can pause the process when sending -STOP
-TRAP does nothing
geekosaur: the pids are the same 18:27
huh, -QUIT worked 18:34
but the dump is rather useless 18:43
domidumont: without knowing any more details I'd say the newer libuv version is the problem 18:56
github.com/libuv/libuv/compare/546...4dc449e25c
a lot of changes that could be at fault
though, bisecting this is not a very fun task 18:57
domidumont interesting. I've install libuv1-dbg and the backtrace shows more stuff -> posted on github ticket 19:06
FROGGS: ^^ some MVM symbols do show up 19:07
FROGGS ohh nice 19:08
I posted mine... weird that they are different 19:09
I guess yours makes more sense 19:10
domidumont I test with package generated by debian packaging and installed the package containing the debug symbols. 19:11
FROGGS my dump is from the debian libuv package also 19:12
since the libuv that's shipped with moarvm doesnt make it hang
I'm going to bed a little bit early today... gnight 19:14
19:17 Ven_ joined 19:40 ilbot3 joined 20:35 Ven_ joined 20:54 Ven_ joined 21:13 BinGOs_ joined 21:15 d4l3k_ joined 21:18 BinGOs joined, JimmyZ_ joined 21:25 flaviusb joined
dalek arVM: 736364c | timotimo++ | src/strings/ops.c:
dogbert17++ found this memleak in ord_basechar_at
 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

Powered by Cro and the Raku® Programming Language.

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

Thank you!