|
00:10
woolfy left
00:14
tgt joined
01:14
tgt joined
02:15
tgt joined
03:16
tgt joined
|
|||
| JimmyZ | s | 03:17 | |
|
03:22
cognominal joined
03:46
jnap joined
04:03
colomon joined
04:17
tgt joined
04:30
colomon joined
04:41
colomon joined
05:17
tgt joined
06:18
tgt joined
06:49
jnap joined
07:28
FROGGS joined
07:49
jnap joined
07:54
woolfy joined
08:12
woolfy left
08:50
jnap joined
08:58
JimmyZ joined
09:25
FROGGS[mobile] joined
09:51
jnap joined
10:45
colomon_ joined
10:52
jnap joined
11:53
jnap joined
12:10
FROGGS joined
12:13
ggoebel11118 joined
12:25
brrt joined
|
|||
| tadzik | huh. Is x86 really more widely used than x86_64 these days? | 12:52 | |
| brrt: | |||
| brrt | x86_64 is a superset of x86 so yeah :-) | 12:53 | |
| that said | |||
| jnthn | x86_64 is easier to JIT for I guess in so far as you've lots of registers :) | ||
|
12:53
jnap joined
|
|||
| brrt | i'm not sure if jitting-for-x86 on a compiled-for-x86_64 moarvm is not opening a way for problems | 12:54 | |
| the 'easier' part was also high in my book jnthn | |||
| but i was thinking more about 64 bit registers :-) | |||
| jnthn | brrt: It may be an issue. | ||
| brrt: And yeah, since .i64 is used everywhere in the VM... :) | |||
| brrt: You'll certainly have an easier time of it. | 12:55 | ||
| brrt | i'm totally and perfectly fine with x86_64 | ||
| i used to think i still had an x86 atom processor in use | |||
| but that happens to run x86_64 just as well | |||
| tadzik | ah, atoms. We meet again | ||
| oh, cool | |||
| brrt | right | ||
| by the way, i borrowed 'compilers' (modern dragon book) from the library | 12:56 | ||
| quite a bit to work through, but i think i'll manage | |||
| jnthn | :) | ||
| Modern Dragon. Breathes fire while surfing the internets using its iPhone... | 12:57 | ||
| brrt | i think the code generation chapter is of most relevance to my projects | ||
| its a good book :-) | |||
| jnthn | oops, I forgot to lunch... | 12:58 | |
| nwc10 | you are the new ilmari? | ||
| brrt | who is ilmari? | ||
| nwc10 | somone in london.pm who consistently forgets to have lunch | 12:59 | |
| jnthn | I don't consistently do it. :) | ||
| nwc10 | that is good to hear | ||
| jnthn | Guess today is some mixture of got up late, depressed, and burried in some refactor of some $dayjob thing | 13:00 | |
| Anyways...gonna go find food. bbiab. | |||
| tadzik | oh, I borrowed that from work too :) | 13:09 | |
|
13:11
zakharyas joined
13:53
jnap joined
14:24
btyler joined
|
|||
| moritz | can github.com/MoarVM/MoarVM/issues/62 be closed? | 15:28 | |
| looks like it can | 15:29 | ||
| I'm closing it now | |||
| if that's wrong, please re-open | |||
| jnthn | Weird, I thought I commented/closed that... | 15:30 | |
| moritz++, anyway | |||
| moritz | yes, you wrote 'fixes #62' in the commit, and it says "referenced by commit ...", but didn't close it | ||
| iirc 'closes #62' would actually close it :-) | |||
| jnthn | d'oh, yes :) | ||
| brrt | i had no idea github read your commits to such detail | 15:32 | |
| japhb | brrt: Pretty common with systems that provide both VCS and bug tracker integration (I've seen in it several such systems) | 15:33 | |
| brrt | i've seen none such systems :-) | 15:34 | |
| jnthn | Yeah, it's useful when you use it correctly :) | ||
| brrt | but now i do | ||
|
16:35
FROGGS[mobile] joined
|
|||
| retupmoca | could I get someone with a commitbit to look at github.com/MoarVM/MoarVM/pull/86 ? | 17:45 | |
| jnthn | retupmoca: I'll get to it in a bit, just wrapping up $dayjob tasks for the day here. | 17:46 | |
| retupmoca | No problem, just making sure it doesn't get lost in the shuffle :) | 17:47 | |
|
17:58
benabik joined
17:59
benabik joined
19:18
rurban joined
|
|||
| dalek | arVM: b5ea924 | (Andrew Egeler)++ | src/strings/decode_stream.c: Fix decodestream_bytes_to_buf eating too much data When decodestream_bytes_to_buf needed less data than available in the buffer, it was incorrectly updating the pointer to the beginning of the buffer data. This lead to a loss of data when doing small socket reads, for example. |
20:15 | |
| arVM: 9375249 | jonathan++ | src/strings/decode_stream.c: Merge pull request #86 from retupmoca/master Fix decodestream_bytes_to_buf eating too much data d93a733 | moritz++ | src/core/interp.c: Revert "check for invalid code points (jvm port)" This reverts commit c5f3b5378bbff39ec76798f54ec0ccd2b2684656. We actually want to allow all codepoints, but joint, new understanding of what the Unicode consortium wrote |
|||
| jnthn | retupmoca: If you have time to write a spectest, that'd be great. | ||
| retupmoca: Thanks for the patch. | |||
| retupmoca | jnthn++ | 20:19 | |
| I would write a spectest for this in roast/S32-io or somesuch? | |||
| (I found the issue while playing with sockets, but this is actually a bug in strings?) | |||
| or are there moarvm tests somewhere? | 20:22 | ||
| jnthn | retupmoca: Yes, there's a bunch of socket tests. | ||
| retupmoca: A spectest is the thing to add | 20:26 | ||
| retupmoca | jnthn: ok, I'll do that - hopefully either tonight or tomorrow | 20:30 | |
| jnthn: I assume I should generally be writing a spectest when I write a patch? | 20:31 | ||
| moritz | retupmoca: that's preferrable, because otherwise it'll regress eventually | 20:32 | |
| retupmoca: though we are aware that not all patches are equally testable | |||
| jnthn | retupmoca: Yes, a spectest or an NQP test if that's more fitting | 20:33 | |
| retupmoca: MoarVM kinda takes those two as its test suite by proxy. | |||
| moritz | jnthn: are there plans to have a separate moarvm test suite eventually? | 20:34 | |
| jnthn | moritz: Eventually. :) | 20:38 | |
| Time for tonight's round of parallel GC debuggering! | 20:58 | ||
| japhb | \o/ # GC debuggering | 21:00 | |
.oO( "Why did they rename the Buggers to Formics?" ) |
21:01 | ||
|
21:02
woolfy joined
|
|||
| tadzik | jnthn++ # it's dangerous to go alone, take this karma | 21:02 | |
| jnthn | \o/ | 21:03 | |
| Yeah, I dunno what this bug is gonna turn out to be... | |||
| japhb | I predict the character count to fix it will be inversely proportional to the time taken to find it. | 21:05 | |
| jnthn | Samma | 21:08 | |
| japhb | huh? | ||
| jnthn | uh | 21:09 | |
| Same :) | |||
| japhb | oh, gotcha. Had a feeling, but wasn't sure. :-) | ||
| tadzik | it's usually like this, ain't it | 21:40 | |
| I remember fixing bugs that took one character per 8 hours | 21:41 | ||
| (damned xslt) | |||
| jnthn is gradually closing in on it, much thanks to conditional breakpoints and the awesome hardware-supported data breakpoints | 21:50 | ||
| aarrrghh | 21:54 | ||
| Seems we had 2 bits of code doing the same thing. | 21:57 | ||
| And running both. | 21:58 | ||
| And running one at a time that clears gen2 liveness bits ahead of the time we can if we've multiple threads. | |||
| I moved the call to the code yesterday, but wouldn't have imagine there was a second version of it elsewhere being called in a completely different place... | 21:59 | ||
| timotimo | uh oh | ||
| jnthn | We'll soon know if it's the bug I'm looking for | 22:00 | |
| But it cleanly explains the problem I've been seeing | |||
| (with a 4k nursery everything takes forever) | |||
| (especially with gc orch logging on) | 22:01 | ||
| Yeah, it's into 9000+ collects | |||
| Never made it past 10,000 before | |||
| uh, past 8,000 | |||
| Wonder how long this runs for... :) | |||
| More than 15,000 apparently :) | 22:03 | ||
| ooh, and it exited cleanly. | |||
|
22:09
tgt joined
|
|||
| japhb | \o/ # Very nice indeed, jnthn | 22:13 | |
| Are you spectesting now? | |||
| jnthn | The bad news is this wasn't the only problem, but it's a notable improvement. | 22:14 | |
| japhb: Yes, doing to do so. | 22:15 | ||
| The other problem causes some kind of explosion in the validator, of all places. | |||
| japhb | eww | 22:16 | |
| jnthn | Man, a debug build ain't the speediest thing to spectest with | 22:19 | |
| ...he says, realizing that it's probably about the speed of an optimized Parrot running spectest | 22:20 | ||
|
22:20
cognominal joined
|
|||
| jnthn | Passed the conc spectests that are enabled under the harness, anyways. | 22:27 | |
| dalek | arVM/moar-conc: 8486c7f | jnthn++ | src/core/threads.c: Missing MVMROOTs. |
22:30 | |
| arVM/moar-conc: 42cb24e | jnthn++ | src/gc/orchestrate.c: Don't duplicately process the main thread. |
|||
| arVM/moar-conc: 3c6e8ad | jnthn++ | src/gc/ (3 files): Remove duplicate gen2 root cleanup in wrong place. Somehow, we had two functions to do this, called in different places. Eliminate the one and the call to it, and then moved the other call to a safe place (so we are certain we do the cleanup before we go taking away the live bits). |
|||
|
22:36
jnap joined
|
|||
| jnthn | I may have a lead on the validator fail. | 22:36 | |
| timotimo | good luck eith that! | 22:38 | |
| japhb | You're having a good debugging day. :-) | ||
| jnthn | Well, this is partly using hours of debugging last night, where I thought at one point the two bugs might be one, and then it became clear they weren't. | 22:39 | |
| japhb | Still, the good thing about fixing this now is that people doing pure Perl 6 code will have a lot fewer mysterious issues. (Which is why I was happy as a clam when nwc10++ started doing his GC abuse testing.) | 22:41 | |
|
22:43
woolfy left
|
|||
| jnthn | We're going to have some more of these to fix, I expect. But yeah, good to hunt the most immediate ones before it's merged. | 22:44 | |
| yay, the fix I hoped would help seems to | 22:47 | ||
| jnthn reduces to a smaller nursery | |||
| japhb | Given that you already had it at 4K, how small can it go? | 22:50 | |
| jnthn | oh, the last one I just had it at was 32K | 22:51 | |
| Which was enough to show up the bug. | |||
| 4K is stressing it harder | |||
| You can get down to around 512 bytes | |||
| Or you can do what nwc10++ did and force a GC run every allocation. | 22:52 | ||
| (He did more than just that, but that was a part of it.) | |||
| dalek | arVM/moar-conc: 7d55b5a | jnthn++ | src/ (3 files): Make sure the frame usecapture points at is ref'd. We kinda got away with not doing this before, when the cur_usecapture could never be collected. Now they can be when a thread terminates, so protection is essential. |
||
| japhb imagines using a floppy drive sector as swap for the nursery | |||
| jnthn | 'cus that'd be fast! :) | 22:53 | |
| Well, lock.t is happy with the 4k nursery | |||
| jnthn tries thread.t | |||
| This'll take forever... :) | |||
| Survived. | 22:57 | ||
| jnthn pours an ale | 23:05 | ||
| The spectests I've got clean so far on r-m pass with an optimized build too | 23:10 | ||
| There's some work to go on the time-based things, but I'm tempted to merge these branches so I can get feedback from daily roast, plus others, if things pass elsewhere. | 23:11 | ||
| There's not really a strong reason for me to do the rest in branches. | |||
| *crickets* :P | 23:12 | ||
| It'll give timo somthing to mention in the weekly news too :) | |||
| dalek | Heuristic branch merge: pushed 39 commits to MoarVM by jnthn | 23:17 | |