|
01:18
vendethiel joined
|
|||
| [Coke] | moar is failing 40+ tests on rakudo on os x. | 01:29 | |
| er. | |||
| sorry, on hack.p6c.org | |||
|
01:47
ilbot3 joined
01:50
colomon joined
01:57
prammer joined
|
|||
| [Coke] | not able to build rakudo-j on my 4G laptop anymore. | 02:12 | |
| (nqp-j, even) | |||
|
02:20
vendethiel joined
02:51
vendethiel joined
03:52
vendethiel joined
04:34
ggoebel2 joined
05:12
vendethiel joined
05:42
vendethiel joined
06:07
vendethiel joined
06:58
FROGGS joined
|
|||
| FROGGS | o/ | 07:00 | |
| lizmat | [Coke]: I have no trouble building JVM rakudo HEAD on OS X | 07:20 | |
|
07:32
TimToady joined
07:46
vendethiel joined
07:47
zakharyas joined
08:52
vendethiel joined
|
|||
| jnthn build nqp-j only a day or two ago 'cus he was working on adding the multidim stuff | 08:52 | ||
|
09:40
vendethiel joined
10:13
vendethiel joined
12:05
rurban joined
|
|||
| [Coke] | lizmat, jnthn (whoops, wrong window on the jvm stuff). I remember the build being fiddly ages ago and needing to change how much memory we asked for during the build. I may have lost a local mod (this is an old laptop) | 12:17 | |
| will just hope he gets the 16G one back soon. | |||
| dalek | arVM: f22142b | hoelzro++ | src/io/procops.c: uv_close a proc handle when we're done reading Fixes Rakudo RT #125616 uv_read_stop prevents further reads from being scheduled on a handle, but apparently doesn't close the OS file descriptor. This caused a runaway descriptor allocation when tapping standard output or error on Proc::Async |
13:09 | |
| jnthn | hoelzro++ | 13:13 | |
| timotimo | good catch, hoelzro++ | 13:14 | |
| jnthn | hoelzro: Don't suppose you could commit a test for that? | ||
| hoelzro | jnthn: sure, in roast? | 13:15 | |
| jnthn | Please | ||
| hoelzro | timotimo: it's only because I ran into it =) | ||
| timotimo | well, you're apparently doing a better job at actually using our stuff than me ;) | ||
| recently my perl6 activities have been pretty limited | |||
| hoelzro | I'm *really* trying lately to actually use Perl 6 instead of fixing every little problem I encounter | 13:16 | |
| JimmyZ | github.com/MoarVM/MoarVM/blob/f221...ops.c#L715 # how about this one ? | ||
| hoelzro | JimmyZ: that's a good question; I think that also should change | ||
| timotimo | hoelzro: i hate to say you're still fixing problems in core :S | 13:17 | |
| hoelzro | timotimo: xkcd.com/597/ | 13:18 | |
| also, this makes me sad: github.com/search?utf8=%E2%9C%93&a...rchresults | |||
| jnthn | hoelzro: I'll bump MOAR_REVISION/NQP_REVISION also too | 13:19 | |
| Think I'm about to fix another regex engine bug | |||
| timotimo | abort is the thing that makes the process die with SIGABRT? | ||
| hoelzro | jnthn: I might have another change coming | ||
| timotimo: yes | |||
| jnthn | hoelzro: ah, ok | ||
| hoelzro | jnthn: I'm thinking of throwing an adhoc exception for github.com/MoarVM/MoarVM/issues/165 | ||
| just so people (ie. me) are not surprised when that bug happens | 13:20 | ||
| timotimo | so libuv isn't very fault tolerant? | ||
| hoelzro | timotimo: apparently not =/ | ||
| timotimo | yeah, that issue still boggles my mind | ||
| hoelzro | be back shortly; have to see my wife off to work | ||
| jnthn | hoelzro: We could do that for now, yes | 13:22 | |
| hoelzro: I suspect this may be the issue that pushes us away from libuv for sync IO | |||
| hoelzro | alright, I'll get on that then | 13:40 | |
|
13:49
zakharyas joined
|
|||
| hoelzro | jnthn: you can go ahead and bump MOAR_REVISION if you want; that bug is proving more interesting than I'd thought =/ | 13:56 | |
| jnthn | ok :) | ||
| Current ongoing discussion on #perl6 may give me a second NQP change to do anyway | 13:57 | ||
| timotimo first read up to "second NQP" and was like "another??" | 14:00 | ||
| jnthn | hoelzro: Congrats, you win an MSVC warning! | 14:13 | |
| compiling src\io\procops.obj | |||
| procops.c | |||
| src\io\procops.c(699) : warning C4133: 'function' : incompatible types - from 'uv_stream_t *' to 'uv_handle_t *' | |||
| hoelzro | ah, crap | ||
| I *did* see that with GCC; I just forgot to go back and fix it =/ | |||
| jnthn | ah, ok | 14:14 | |
| timotimo | uv kinda plays it fast and loose with those "types" :) | 14:15 | |
| but to be fair, we also treat everything as an MVMCollectable at some points | 14:16 | ||
| i guess it's common practice | |||
| dalek | arVM: d83ec82 | hoelzro++ | src/io/procops.c: Fix compiler warning when using uv_close |
||
| arVM: 07daf04 | hoelzro++ | src/io/procops.c: Use uv_close in Proc::Async read error case as well |
|||
| timotimo | and a language like C++ also does it, it just hides the vtable a bit better? | ||
| hoelzro | timotimo: I think C++ just has rules for when a pointer to type A can be treated as a pointer to type B | 14:17 | |
| commute & | |||
|
14:20
FROGGS joined
|
|||
| jnthn | So, hunting concurrency bugs that are above VM level is getting tricky. | 14:49 | |
| Thankfully, we have The Technology to instrument bytecode | 14:50 | ||
| I think I'm going to see if I can hack up some env-var-enabled overly-simplistic analysis tool to help | |||
| timotimo | that'd be pretty interesting | 14:51 | |
| anything particular you're going to model it after? | |||
| jnthn | That will spot when a thread writes to something that it didn't allocate | ||
| Not really...I know about some of the good algorithms but I don't actually need that level of sophistication yet | 14:52 | ||
| (The good algos want you to do stuff like vector clocks, establish the happens-before relation, and so on) | 14:53 | ||
| But the bugs I've got seem to be where at some point we end up with supposedly shared-nothing code accidentally sharing | |||
| timotimo | right | 14:54 | |
| jnthn | And while some were MoarVM's fault, many of them are code-gen bugs | ||
| timotimo | that seems sorta-easy to spot, as we have an owner field in all objects already | ||
| jnthn | Right | ||
| timotimo | cool | ||
|
14:56
JimmyZ_ joined
15:15
lizmat joined
15:23
Ven joined
16:20
hoelzro_trying_w joined,
retupmoca joined,
timotimo joined
16:40
cognominal joined
17:12
vendethiel joined
17:34
vendethiel joined
18:13
zakharyas joined
19:41
Peter_R joined
20:32
colomon joined
|
|||
| dalek | arVM: 5227f5e | jnthn++ | / (15 files): Add cross-thread write debug logging. Enabled by setting MVM_CROSS_THREAD_WRITE_LOG in the environment. Uses bytecode instrumentation and squeals when one thread does a write to an object allocated by another thread, and isn't under lock. (You may set MVM_CROSS_THREAD_WRITE_LOG_INCLUDE_LOCKED in order to include the writes done while holding a lock also). Does not yet deal with binds to lexicals in a frame entered by another thread, but gets object, array, and hash mutations nailed. |
20:52 | |
|
20:54
colomon joined
|
|||
| jnthn | Nicely shows up that something very odd is going on with RT #125161 | 20:59 | |
| hoelzro | yaaaaaay | 21:00 | |
| jnthn++ | |||
|
21:01
synbot6 joined
|
|||
| jnthn | Of course, I've still to figure out what exactly, but it gives me stack traces showing where the unexpected cross-thread writes happen. | 21:02 | |
|
21:20
TEttinger joined
21:38
colomon joined
|
|||
| nwc10 | jnthn: seems that Rakudo build fails becaose instrument/crossthreadwrite.h is not installed | 21:51 | |
| In file included from src/vm/moar/ops/perl6_ops.c:2:0: | |||
| /home/nicholas/Sandpit/moar-san/include/moar/moar.h:179:41: fatal error: instrument/crossthreadwrite.h: No such file or directory | |||
| jnthn | nwc10: interesting... | 21:52 | |
| I didn't actually try one of those :) | 21:53 | ||
| Though, I didn't bump MOAR_REVISION either ;) | |||
| dalek | arVM: 938098d | jnthn++ | build/Makefile.in: Fix "make install" to know about src/instrument. nwc10++ for reporting. |
21:54 | |
| jnthn | That should do it. | ||
.oO( If he calls it "moar san", does that mean he considers it his equal? :) ) |
21:56 | ||
| nwc10 | it has friends such as moar-O2, moar-g moar-32 and even moar-clang-O2 | 21:57 | |
| hoelzro | why didn't Travis pick up that failure? | 21:58 | |
| nwc10 | not smoking the newest crack? Just the current versions? | 22:01 | |
| or only re-doing Rakudo if Rakudo changes? | |||
| hoelzro | MoarVM has its own Travis config, doesn't it? | 22:02 | |
| nwc10 | either way, it's a good question, and it would be useful if there was a travis that could smoke master/master/nom for any change in all 3 (er 4, roast) | ||
| but this isn't me volunteering to figure out how to do it :-) | |||
| hoelzro | =) | ||
| I wanted to hack a little Travis script that would verify my modules build against the latest Rakudo once a day, if they hadn't been built that day | 22:03 | ||
| hoelzro .oO( Triple Travist? ) | |||
| now I need to set it up just for the name =) | 22:04 | ||
| it's a shame that Rakudo doesn't spectest in Travis as well | |||
| jnthn | Note that Rakudo was only affected if you're a HEAD-chaser | 22:05 | |
| Most folks follow the recomended NQP/Moar revisions, and I suspect the Travis builds do too | |||
| hoelzro | the Travis builds use both the NQP_REVISON and NQP master | 22:06 | |
| github.com/rakudo/rakudo/blob/nom/...is.yml#L27 | |||
| nwc10 | to be clear (and I don't think anyone misunderstood me, but to be sure to be sure) I meant "would be useful in addition to what we have currently" | 22:07 | |
| jnthn | aha | 22:09 | |
| hoelzro++ # knowing where to look up this stuff :) | |||
| hoelzro | this sounds right up our alley: github.com/travis-ci/travis-ci/issues/249 | 22:10 | |
| jnthn | cool :) | 22:12 | |
| OK, enough for me today | 22:13 | ||
| 'night, y'all | |||
| hoelzro | good night jnthn | ||
|
23:16
nebuchadnezzar joined
|
|||