|
00:08
camelia joined
00:25
benabik joined
00:32
colomon joined
01:11
ingy joined
01:12
benabik joined
01:36
brother joined
03:06
ilbot3 joined
04:23
cognominal joined
04:51
jnap joined
05:43
cognominal joined
05:51
jnap joined
06:31
FROGGS joined
06:52
jnap joined
07:36
FROGGS joined
07:53
jnap joined
08:09
dalek joined
09:32
odc joined
|
|||
| 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 | ||
| FROGGS | hmmmm | ||
| jnthn | Well | ||
| I guess it *could* happen | |||
| FROGGS | I don't understand this: nopaste.info/3966723b4a.html | ||
| jnthn | But... | ||
| FROGGS | handle is NULL, but body is set | ||
| jnthn | I sorta hope not | 10:36 | |
| FROGGS | bit right before that explosion we obtain body from handle | ||
|
12:08
woolfy left
14:04
jnap joined
|
|||
| rurban_ | a libuv runloop calls user code usually, which triggers GC | 14:18 | |
| FROGGS | but we are in the middle or processing an op | ||
| but yeah, I fear it is doing something of that kind... | 14:19 | ||
| but hmmmm | |||
| maybe it makes sense to dump libuv's queue at that point | |||
| so that we can prove that there is only a read request in it or so | 14:20 | ||
|
14:21
colomon joined
|
|||
| 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 | |
| If so, that'll be dealt with in my upcoming changes... | |||
| FROGGS | hmmm, it might be the case here... | 14:25 | |
| but I don't believe it | |||
| handle is NULL here github.com/MoarVM/MoarVM/blob/mast...ops.c#L652 | 14:26 | ||
| but body is a valid pointer, and this one was obtained from handle | |||
| and there is nothing that can trigger between obtaining body and the access to handle | |||
|
14:32
jnap joined
15:34
lizmat joined
15:49
colomon joined
16:10
colomon joined
17:26
cognominal joined
17:33
benabik joined
17:51
FROGGS joined
18:50
colomon joined
|
|||
| timotimo | nwc10: thank you very much for fixing varint stuff for me | 19:30 | |
| FROGGS | so the maybe-varintfix branch is obsolete now? | 19:31 | |
| timotimo | i'm not sure | 19:33 | |
| jnthn | The nwc10++ patches look good to me... | 19:35 | |
| nwc10 | FROGGS: no, it's your 2 patches plus mine | ||
| timotimo: what we really missed was tests at the start | |||
| timotimo | yeah, i really should have written some | 19:36 | |
| jnthn | nwc10: Ah, these you've sent should be applied atop of that branch? | ||
| FROGGS | cool :o) | ||
| maybe it is because I am not mathemagician, but I prefer if/else to log in these places | 19:37 | ||
| I failed to write good tests :( | |||
| nwc10 | jnthn: yes. Sorry, I thought I said that somewhere | 19:39 | |
| actually, there are 3 for NQP and 1 for MoarVM | |||
| given how things are split up :-( | |||
| FROGGS | at least it is under our control :o) | ||
| benabik | A long chain of if statements can be pretty bad for branch prediction. | ||
| FROGGS | is seven or eight "long" ? | 19:40 | |
| 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 | ||
| 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) | ||
| jnthn applies all the patches, tests... | 19:45 | ||
| nwc10 | tests++ | ||
| I assume it will also need a Moar bump in NQP | 19:46 | ||
| jnthn | *nod* | 19:47 | |
| NQP tests you added pass here. | |||
| Just doing a Rakudo build now | |||
| FROGGS | test all the things! /o/ | 19:49 | |
| dalek | arVM: 0876c8c | (Tobias Leich)++ | src/6model/serialization.c: possible fix for varintsize(2147483647) |
||
| arVM: 9acff8c | (Tobias Leich)++ | src/6model/serialization.c: do not use abs(), nwc10++ |
|||
| MoarVM: 4b1c237 | nicholas++ | src/6model/serialization.c: | |||
| MoarVM: Fix various errors in varint serialisation code. | |||
| MoarVM: | |||
| MoarVM: write_varint9() was writing a 9th byte when only 8 should have been written. | |||
| MoarVM: read_varint9() was reading a 9th byte when only 8 should have been read. | |||
| MoarVM: | |||
| MoarVM: It was also failing to perform its bit shifting operations using 64 bit types, | |||
| MoarVM: and had an off-by one error in the shifting if a 9th byte was read. | |||
| jnthn | nwc10++ # all applied, thank you! | 19:55 | |
| nwc10 | I think 2 more MoarVM patches and once ohloh catches up I'm into the top 10 | 19:56 | |
| timotimo | am i i nthe top 10, too? :) | 19:59 | |
| jnthn | what about me? :) | 20:00 | |
| nwc10 | everyone find themselves: www.ohloh.net/p/moarvm/contributors | 20:01 | |
| benabik did not expect to be in the top 10. | |||
| FROGGS | \o/ | 20:05 | |
| jnthn | Gah, I'm top? That means I'm still terrible at delegating... | 20:07 | |
| FROGGS | *g* | ||
| moritz has no idea how VMs work, and is only on that list by accident | 20:15 | ||
| 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 | |||
| moritz | why did I read "strtoll" at first? :-) | 20:19 | |
| benabik | .oO( Why would you use strtoll for a short int? ) |
20:20 | |
| jnthn | moritz: I C what you did there... | 20:56 | |
| timotimo | >_> | 21:00 | |
|
21:56
vmspb joined
|
|||
| timotimo | now i have a debug session in which a concatenation result doesn't work as expected | 22:06 | |
| or at least i thinnk so | |||
| FROGGS | huh | 22:07 | |
| timotimo | my debug printing of the resulting string looks like 'r(r()(r(NQPCORE)(.setting.moarvm))' | ||
| (i'm trying to make MVM_string_concatenate use ropes/strands instead of flattening the strings all the time) | |||
| jnthn | Is that wrong? | 22:08 | |
| iirc the problem was actually when you went comparing them. | |||
| timotimo | it should read ./NQPCORE.setting.moarvm | ||
| but it may just be my printing logic being wrong | |||
| jnthn | oh, it lost the ./? | ||
| timotimo | it kind of looks like that | ||
| jnthn | hm | ||
| timotimo | i need to singlestep back in there | 22:09 | |
| i can't step backwards unfortunately | |||
| i don't seem to have any brain capacity for such things right now :| | 22:11 | ||
| but i suppose i should push my gdb plugin | 22:13 | ||
| actually i kind of feel like going home and falling into bed | 22:17 | ||
| 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. | ||
| timotimo | \o/ | 22:19 | |
| perl 6 stuff would be the io refactor/rewrite? | |||
| jnthn | Yeah, I think that's probably what I should do :) | ||
| timotimo | so, i just had a probably crazy idea | ||
| jnthn | Weekend looks clearish too. | ||
| timotimo | if we determine that two strings are equal | ||
| should we just go ahead and share the space? | |||
| jnthn | Hmm | 22:20 | |
| timotimo | of course that's not much help if we compare two substrings of two unrelated strings | ||
| and that's not so simple to find out maybe? | |||
| jnthn | Only if you can make that happen in an atomic way, so we don't lose the benefit over immutable strings. | ||
| timotimo | hm. | 22:21 | |
| anyway, i don't eve nknow how the strings behave WRT GC and moving and strands | |||
| jnthn | Strands are individually collectable, iirc. | ||
| Precisely so sharing them is easy. | 22:22 | ||
| 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:23 | |
| jnthn | At the moment, probably not. | 22:24 | |
| That's a Known Difficult Trade-off | |||
| Rakudo JVM suddenly got slower at certain things (of note, parsing the JAST dump) when they changed substring semantics recently. | 22:25 | ||
| You can cause pain whichever you choose. | |||
| (Pain of always copying, vs. pain of non-collection.) | |||
| Well, not non-collection so much as uncollectability. | 22:26 | ||
| timotimo | sounds legit | ||
| 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:27 | |
| FROGGS | the code will get clever over time anyway, so it might make sense to start with the easy solution | 22:29 | |
| 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:30 | ||
| and, well, gnight :o) | 22:31 | ||
| jnthn is somewhat optimistic he can keep unwarranted cleverness out of Moar... | |||
.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:34 | ||
| timotimo | mhm | 22:35 | |
| jnthn | </machiavelli> # :) | ||
| 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"? :) | ||
| 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? | ||
| so i could build one of these frame filter thingies? | 22:39 | ||
| gotta run | |||
| jnthn | Do you have tc available? | ||
| timotimo | yes | ||
| and i can step a frame up into the interpreter itself at any given moment | |||
| jnthn | See the backtrace producing code maybe? | ||
| Or the annotation lookup? | |||
| MVM_bytecode_resolve_annotation(tc, &tc->cur_frame->static_info.body, *tc->interp_cur_op - *tc->interp_bytecode_start) /* or so */ | 22:42 | ||
| timotimo | thx | 22:47 | |
| jnthn | pzh | 22:49 | |
| timotimo | a tiny bit early for my tram | 22:55 | |
| but better than missing it | |||