| colomon | Woah. Trying to write a simple p6 script to shuffle a list of MP3 files and play them. Unfortunately, it appears run is non-blocking, and my system is now playing 37 tracks on top of each other… | 00:30 | |
| is there a standard idiom for “run to completion” for Procs spawned by run? | 00:36 | ||
| seems like $proc.out.slurp works, but that seems roundabout | |||
| dang it, wrong channel. apologies | 00:41 | ||
|
01:08
sivoais joined
01:48
ilbot3 joined
04:27
KDr2 joined
06:10
brrt joined
06:11
domidumont joined
06:16
domidumont joined
06:34
domidumont joined
06:48
brrt joined
|
|||
| nwc10 | timotimo: thanks. I wondered if it was *something* like that, but didn't know enough of the details | 06:58 | |
| lizmat | is it known that --profile-compile is borked at the moment ? | 07:44 | |
| brrt | … no | 07:52 | |
| not to me, at least | |||
| also, good * | |||
| lizmat | $ perl6 --profile-compile -e '' | 07:59 | |
| Writing profiler output to profile-1496735990.3746.html | |||
| Segmentation fault: 11 | |||
| brrt | ouch | 08:00 | |
| lizmat | $ perl6 --profile-compile -e '' | ||
| Writing profiler output to profile-1496736000.01859.html | |||
| moar(16064,0x7fffe69f53c0) malloc: *** error for object 0x7fe80bfc7400: incorrect checksum for freed object - object was probably modified after being freed. | |||
| *** set a breakpoint in malloc_error_break to debug | |||
| and more like that | |||
| nwc10 | ASAN thinks that this is very interesting and makes lots of pretty colours that don't show up on a paste: paste.scsys.co.uk/564352 | 08:05 | |
| brrt | buffer overflow yay | 08:40 | |
| jnthn suspects 2baad5f7060e72dfc8 | 08:49 | ||
| timotimo: ^^ | |||
| Geth | MoarVM: 0de28f822a | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c Fix warning from excess args to sprintf. |
08:53 | |
| MoarVM/std-with-syncfile: 8286fe915c | (Jonathan Worthington)++ | 3 files Switch std* to use syncfile, not syncstream. The difference was enforced by libuv's very different APIs for working with files and TTYs. Now we're moving away from that for synchronous handles, syncfile's code is mostly right; it will be tweaked in some upcoming commits for the cases where it is not. |
09:08 | ||
| MoarVM/std-with-syncfile: 0e3ab617c3 | (Jonathan Worthington)++ | 2 files Remove newly-dead code. |
09:11 | ||
| jnthn | huh, only just realized that syncfile has a ->filename field in its data that it sets, frees, but never actually uses for anything | 09:12 | |
| Geth | MoarVM/std-with-syncfile: 0b46dc6d97 | (Jonathan Worthington)++ | src/io/syncfile.c Kill off unused ->filename slot of syncfile. We stored to it, cleaned it up later, but never used the value for anything. |
09:15 | |
|
09:22
robertle joined
|
|||
| Geth | MoarVM/std-with-syncfile: 8a768d2096 | (Jonathan Worthington)++ | src/io/syncfile.c Add fake tell for unseekables. This was provided by syncstream previously. |
09:23 | |
| MoarVM/std-with-syncfile: 18a0bd2bc6 | (Jonathan Worthington)++ | src/io/syncfile.c Fix EOF handling on unseekables. |
09:29 | ||
| jnthn crosses fingers and spectests | 09:31 | ||
|
09:33
lizmat joined
|
|||
| jnthn | Nice, a todo pass in t/spec/S16-io/handles-between-threads.rakudo.moar :) | 09:33 | |
| Alrighty, that looks all good on Linux | |||
| I should give it a spin on Windows before merging, but once that branch is merged then $*IN, $*OUT, and $*ERR are also free of libuv and thus the passing-between-thread restrictions. | 09:34 | ||
| Geth | MoarVM: b0b5cf12c2 | (Jonathan Worthington)++ | 3 files Support binding handles to fds in async procs. |
10:10 | |
| timotimo | the problem in the profiler was a simple off-by-one | 10:21 | |
| Geth | MoarVM: 2eeafefc91 | (Timo Paulssen)++ | src/profiler/instrument.c fix off-by-one in profiler node GC |
10:22 | |
| timotimo | oh, i should have put a nwc10++ | ||
| i wonder why it didn't explode for me ever since i made that change? | 10:38 | ||
| brrt | i have an interesting observation to add | 10:41 | |
| you know how i added a (hard) breakpoint mechanism to the JIT | |||
| well, in gdb, that causes a segv in some unrelated later section | |||
| it is only in lldb that it traps as it should | |||
|
10:41
AlexDaniel joined
|
|||
| timotimo | huh | 10:42 | |
| it doesn't upset the register allocator or anything, right? | |||
| brrt | nope | ||
| it's an error in gdb as far as i can tell | |||
| timotimo | fascinating | 10:43 | |
| brrt | presumably, when gdb captures a trap, it looks into some memory structure, but since the JIT put the trap and not GDB, there is no data structure, so it segfaults at some later point | ||
| timotimo | what mechanism do you use to trap this? | 10:44 | |
| nwc10 | timotimo: I didn't find it. I just happened to have an ASAN build handy | ||
| brrt | i'm inserting a 'hard breakpoint' with 'int 3' | 10:45 | |
| timotimo | time to gdb gdb | 11:02 | |
|
11:02
lizmat joined
|
|||
| jnthn | Grrr, no, Windows is going to be somehow "special" over the std-with-syncfile branch :/ | 11:55 | |
| "Reading from filehandle failed: Not enough space" | 11:57 | ||
| WAT! | |||
| ilmari | ENOSPC on _read_?! | 12:00 | |
|
12:01
zakharyas joined
|
|||
| jnthn | ENOMEM apparently | 12:06 | |
| ilmari | ah | ||
| doesn't it read into an already allocated buffer? | |||
| jnthn | Yes | 12:07 | |
| ilmari | actually, POSIX allows ENOMEM | ||
| jnthn | Though I'm calling _read which is something of an emulation on Windows | ||
| ilmari | I guess in case it needs temporary buffers | ||
| jnthn | This only happens on Windows, and only when the read is from stdin, and even then only when it's a terminal | 12:09 | |
| nwc10 | it's enough to drive you to drink^Wlunch | ||
| jnthn | And even that isn't the whole story | 12:10 | |
| nqp-m -e "say(stdin().get)" | |||
| oh wait | 12:11 | ||
| That's 'cus a version I compiled with a hack in it to try something out fixes the problem | |||
| It seems if you pass too big a number to _read then the error occurs o.O | 12:12 | ||
| msdn.microsoft.com/en-us/library/w...s.85).aspx is the docs for the Windows API that reads from a console. | |||
| "The storage for this buffer is allocated from a shared heap for the process that is 64 KB in size. The maximum size of the buffer will depend on heap usage." | |||
| 32767 gives the same error | 12:13 | ||
| 16387 is ok | 12:14 | ||
| Guess I can just detect when this might be about to go horribly wrong and cap it | 12:17 | ||
| Geth | MoarVM/std-with-syncfile: a968d2759c | jnthn++ | src/io/syncfile.c Fix reading from consoles on Windows. |
12:23 | |
| jnthn | REPL is happy again :) | 12:24 | |
| spectesting but can probably merge this | 12:25 | ||
| Geth | MoarVM/master: 7 commits pushed by (Jonathan Worthington)++, jnthn++ | 12:33 | |
| jnthn | That completes the work to get $*IN, $*OUT, and $*ERR reliably usable from threads other than the main one. | 12:34 | |
| [Coke] | jnthn++ | 12:35 | |
| jnthn | So, that's files and sockets addressed. | ||
| Proc remains | 12:36 | ||
| Will look at that later in the week :) | |||
| Well, continue looking at | |||
|
14:32
lizmat joined
14:34
AlexDaniel joined
14:49
domidumont joined
15:48
lizmat joined
16:08
sivoais joined
16:59
lizmat joined
17:09
ZofBot joined
17:16
zakharyas joined
17:44
eveo joined,
eveo left
17:45
eveo joined
17:51
ZofBot joined
18:00
lizmat joined
|
|||
| eveo | $ ./moar --version | 18:00 | |
| This is MoarVM version | |||
| Looks like building moar from a shallow checkout has bogus version. And now nqp fails to build because it can't figure out version. | 18:01 | ||
| )$ git describe | |||
| fatal: No names found, cannot describe anything. | |||
| Full checkout it is :| Was hoping not to wait forever for it to download. Alas. | 18:03 | ||
| 8 KiB/s .... I guess I have time for a nap :) | 18:10 | ||
|
18:12
ZofBot joined
18:37
domidumont joined
|
|||
| jnthn | If you don't need the git history, just grab a release tarball from www.moarvm.org/releases/ | 18:42 | |
|
18:43
domidumont1 joined
18:48
domidumont joined
18:51
brrt joined
|
|||
| eveo | That's too old. I need rakudo v2017.05.347.g.61.ecfd.5. But it's OK. I sshed into another box with faster connection and ran the stuff there. | 19:07 | |
|
20:30
robertle joined
20:37
lizmat joined
21:20
eveo joined
21:40
AlexDaniel joined
21:49
AlexDani` joined
22:45
eveo joined
22:47
eveo left,
eveo joined
|
|||