Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-11

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

All times shown according to UTC.

Time Nick Message
00:08 camelia joined #moarvm
00:25 benabik joined #moarvm
00:32 colomon joined #moarvm
01:11 ingy joined #moarvm
01:12 benabik joined #moarvm
01:36 brother joined #moarvm
03:06 ilbot3 joined #moarvm
03:06 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:23 cognominal joined #moarvm
04:51 jnap joined #moarvm
05:43 cognominal joined #moarvm
05:51 jnap joined #moarvm
06:31 FROGGS joined #moarvm
06:52 jnap joined #moarvm
07:36 FROGGS joined #moarvm
07:53 jnap joined #moarvm
08:09 dalek joined #moarvm
09:32 odc joined #moarvm
10:35 FROGGS jnthn: when we call "uv_run(tc->loop, UV_RUN_DEFAULT);", is it possible the we execute something that triggers a gc run?
10:35 jnthn No
10:35 FROGGS hmmmm
10:35 jnthn Well
10:35 jnthn I guess it *could* happen
10:35 FROGGS I don't understand this: http://nopaste.info/3966723b4a.html
10:35 jnthn But...
10:35 FROGGS handle is NULL, but body is set
10:36 jnthn I sorta hope not
10:36 FROGGS bit right before that explosion we obtain body from handle
12:08 woolfy left #moarvm
14:04 jnap joined #moarvm
14:18 rurban_ a libuv runloop calls user code usually, which triggers GC
14:18 FROGGS but we are in the middle or processing an op
14:19 FROGGS but yeah, I fear it is doing something of that kind...
14:19 FROGGS but hmmmm
14:19 FROGGS maybe it makes sense to dump libuv's queue at that point
14:20 FROGGS so that we can prove that there is only a read request in it or so
14:21 colomon joined #moarvm
14:23 jnthn This isn't just another case of stashing a pointer in a libuv data structure that points to something the GC may move, is it?
14:23 jnthn If so, that'll be dealt with in my upcoming changes...
14:25 FROGGS hmmm, it might be the case here...
14:25 FROGGS but I don't believe it
14:26 FROGGS handle is NULL here https://github.com/MoarVM/MoarVM/blob/master/src/io/fileops.c#L652
14:26 FROGGS but body is a valid pointer, and this one was obtained from handle
14:26 FROGGS and there is nothing that can trigger between obtaining body and the access to handle
14:32 jnap joined #moarvm
15:34 lizmat joined #moarvm
15:49 colomon joined #moarvm
16:10 colomon joined #moarvm
17:26 cognominal joined #moarvm
17:33 benabik joined #moarvm
17:51 FROGGS joined #moarvm
18:50 colomon joined #moarvm
19:30 timotimo nwc10: thank you very much for fixing varint stuff for me
19:31 FROGGS so the maybe-varintfix branch is obsolete now?
19:33 timotimo i'm not sure
19:35 jnthn The nwc10++ patches look good to me...
19:35 nwc10 FROGGS: no, it's your 2 patches plus mine
19:35 nwc10 timotimo: what we really missed was tests at the start
19:36 timotimo yeah, i really should have written some
19:36 jnthn nwc10: Ah, these you've sent should be applied atop of that branch?
19:36 FROGGS cool :o)
19:37 FROGGS maybe it is because I am not mathemagician, but I prefer if/else to log in these places
19:37 FROGGS I failed to write good tests :(
19:39 nwc10 jnthn: yes. Sorry, I thought I said that somewhere
19:39 nwc10 actually, there are 3 for NQP and 1 for MoarVM
19:39 nwc10 given how things are split up :-(
19:39 FROGGS at least it is under our control :o)
19:39 benabik A long chain of if statements can be pretty bad for branch prediction.
19:40 FROGGS is seven or eight "long" ?
19:41 benabik Given that you're likely to get eight branch misses every time you get to the end, kinda.  But if it's not performance sensitive maybe it doesn't matter.
19:41 nwc10 I suspect most of the time you're going to only hit one or two of the if()s before returning
19:42 benabik *shrug*  It's probably not so bad.  Just something in favor of using a good log function.  ;-)
19:42 FROGGS yeah, you usually don't have numbers > 2**50 in your code (I hope)
19:45 * jnthn applies all the patches, tests...
19:45 nwc10 tests++
19:46 nwc10 I assume it will also need a Moar bump in NQP
19:47 jnthn *nod*
19:47 jnthn NQP tests you added pass here.
19:47 jnthn Just doing a Rakudo build now
19:49 FROGGS test all the things! /o/
19:49 dalek MoarVM: 0876c8c | (Tobias Leich)++ | src/6model/serialization.c:
19:49 dalek MoarVM: possible fix for varintsize(2147483647)
19:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0876c8c638
19:49 dalek MoarVM: 9acff8c | (Tobias Leich)++ | src/6model/serialization.c:
19:49 dalek MoarVM: do not use abs(), nwc10++
19:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9acff8c96d
19:49 dalek MoarVM: 4b1c237 | nicholas++ | src/6model/serialization.c:
19:49 dalek MoarVM: Fix various errors in varint serialisation code.
19:49 dalek MoarVM:
19:49 dalek MoarVM: write_varint9() was writing a 9th byte when only 8 should have been written.
19:49 dalek MoarVM: read_varint9() was reading a 9th byte when only 8 should have been read.
19:49 dalek MoarVM:
19:49 dalek MoarVM: It was also failing to perform its bit shifting operations using 64 bit types,
19:49 dalek MoarVM: and had an off-by one error in the shifting if a 9th byte was read.
19:55 jnthn nwc10++ # all applied, thank you!
19:56 nwc10 I think 2 more MoarVM patches and once ohloh catches up I'm into the top 10
19:59 timotimo am i i nthe top 10, too? :)
20:00 jnthn what about me? :)
20:01 nwc10 everyone find themselves: https://www.ohloh.net/p/moarvm/contributors
20:01 * benabik did not expect to be in the top 10.
20:05 FROGGS \o/
20:07 jnthn Gah, I'm top? That means I'm still terrible at delegating...
20:07 FROGGS *g*
20:15 * moritz has no idea how VMs work, and is only on that list by accident
20:16 jnthn moritz: They just sit in a loop doing stuff depending on what number they see, is all...
20:16 * jnthn takes a short stroll
20:19 moritz why did I read "strtoll" at first? :-)
20:20 benabik .oO( Why would you use strtoll for a short int? )
20:56 jnthn moritz: I C what you did there...
21:00 timotimo >_>
21:56 vmspb joined #moarvm
22:06 timotimo now i have a debug session in which a concatenation result doesn't work as expected
22:06 timotimo or at least i thinnk so
22:07 FROGGS huh
22:07 timotimo my debug printing of the resulting string looks like 'r(r()(r(NQPCORE)(.setting.moarvm))'
22:07 timotimo (i'm trying to make MVM_string_concatenate use ropes/strands instead of flattening the strings all the time)
22:08 jnthn Is that wrong?
22:08 jnthn iirc the problem was actually when you went comparing them.
22:08 timotimo it should read ./NQPCORE.setting.moarvm
22:08 timotimo but it may just be my printing logic being wrong
22:08 jnthn oh, it lost the ./?
22:08 timotimo it kind of looks like that
22:08 jnthn hm
22:09 timotimo i need to singlestep back in there
22:09 timotimo i can't step backwards unfortunately
22:11 timotimo i don't seem to have any brain capacity for such things right now :|
22:13 timotimo but i suppose i should push my gdb plugin
22:17 timotimo actually i kind of feel like going home and falling into bed
22:18 timotimo jnthn: what does your tuit supply look like the coming days?
22:18 jnthn timotimo: Working on $demo-code for Thursday's talk this evening, so I should be able to dedicate tomorrow to Perl 6 stuff.
22:19 timotimo \o/
22:19 timotimo perl 6 stuff would be the io refactor/rewrite?
22:19 jnthn Yeah, I think that's probably what I should do :)
22:19 timotimo so, i just had a probably crazy idea
22:19 jnthn Weekend looks clearish too.
22:19 timotimo if we determine that two strings are equal
22:19 timotimo should we just go ahead and share the space?
22:20 jnthn Hmm
22:20 timotimo of course that's not much help if we compare two substrings of two unrelated strings
22:20 timotimo and that's not so simple to find out maybe?
22:20 jnthn Only if you can make that happen in an atomic way, so we don't lose the benefit over immutable strings.
22:21 timotimo hm.
22:21 timotimo anyway, i don't eve nknow how the strings behave WRT GC and moving and strands
22:21 jnthn Strands are individually collectable, iirc.
22:22 jnthn Precisely so sharing them is easy.
22:23 timotimo OK, but if we have a huge string, take a small substring of that, turn that into a strand and then throw away the huge string, will the beginning and end pieces actually be collected at all?
22:24 jnthn At the moment, probably not.
22:24 jnthn That's a Known Difficult Trade-off
22:25 jnthn Rakudo JVM suddenly got slower at certain things (of note, parsing the JAST dump) when they changed substring semantics recently.
22:25 jnthn You can cause pain whichever you choose.
22:25 jnthn (Pain of always copying, vs. pain of non-collection.)
22:26 jnthn Well, not non-collection so much as uncollectability.
22:26 timotimo sounds legit
22:27 jnthn I fear "clever" solutions here would either a) introduce other confusing performance edge-cases, or b) add enough complexity that a clean, bug-free implementation is rather hard.
22:29 FROGGS the code will get clever over time anyway, so it might make sense to start with the easy solution
22:30 FROGGS at work I try to avoid too clever solutions too, because I usually am on call and I had to debug that code in the middle of the night
22:31 FROGGS and, well, gnight :o)
22:31 * jnthn is somewhat optimistic he can keep unwarranted cleverness out of Moar...
22:34 jnthn .oO( Good architects sometimes have to learn "not to be good", they have to be willing to set aside separation of concerns, simplicity and lose coupling to maintain the performance of the program... )
22:35 timotimo mhm
22:35 jnthn </machiavelli> # :)
22:38 timotimo i kind of wonder why we are building a rope out of "." and "/" anyway :P
22:38 jnthn As in, "shouldn't there be a threshold"? :)
22:38 timotimo jnthn: would you like to quickly type out how to get from the interpreter loop or somewhere nearby to the current filename and line number when you're inside gdb?
22:39 timotimo so i could build one of these frame filter thingies?
22:39 timotimo gotta run
22:39 jnthn Do you have tc available?
22:39 timotimo yes
22:39 timotimo and i can step a frame up into the interpreter itself at any given moment
22:39 jnthn See the backtrace producing code maybe?
22:39 jnthn Or the annotation lookup?
22:42 jnthn MVM_bytecode_resolve_annotation(tc, &tc->cur_frame->static_info.body, *tc->interp_cur_op - *tc->interp_bytecode_start) /* or so */
22:47 timotimo thx
22:49 jnthn pzh
22:55 timotimo a tiny bit early for my tram
22:55 timotimo but better than missing it

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