Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-06-06

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

All times shown according to UTC.

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

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