Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-23

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

All times shown according to UTC.

Time Nick Message
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
02:57 geekosaur joined #moarvm
06:38 Dunearhp joined #moarvm
09:38 vendethiel- joined #moarvm
10:32 FROGGS joined #moarvm
10:32 FROGGS o/
10:32 timotimo o/
10:48 FROGGS any plans for today?
10:49 timotimo well, i have several outstanding work items that'd be good to work on :\
10:50 timotimo one item that i've been pushing further and further forward is making spesh able to handle inlined code better; at the moment we don't discover facts from it and don't really do cross-inline-optimization all that well
10:51 FROGGS ahh
10:51 timotimo more recently, i've been meaning to improve the fixed-size allocator so that it handles multi-threading better - though it'd also be nice if it could get faster in the single-threaded case when a program is very heavy on allocating callframes
10:51 FROGGS can you break one of these tasks apart - into smaller work packages?
10:51 timotimo i'd also like to have some kind of analysis available for serialized blobs, as well as some analysis for the complete state of all our memory allocators
10:52 FROGGS and then say, I want to do #1 until 4 o'clock?
10:52 FROGGS sometimes that keeps me productive
10:52 timotimo good question
10:53 FROGGS I just want to read the scrum guide carefully today, because the next two days will be scrum master course
10:53 timotimo that sounds nice
10:53 FROGGS hope so :o)
10:53 timotimo though i forgot which of the things i've read about so far was the one named "scrum"
10:54 FROGGS hmmm, hard to explain in a few sentences
10:55 timotimo i probably already know it, just can't identify it by the name alone
10:55 timotimo "know about it", more like :)
10:56 FROGGS the result should be that the "customer" will see the progress more often, and can request changes and report bugs while it is still in the works
10:57 timotimo oh, basically "agile"
10:57 FROGGS that's what I basically do since forever, but when doing scrum right, you've got one person that does the coding and another one that does reviews and administration stuff
10:57 FROGGS aye
10:58 FROGGS most of the time I'm kinda alone at work, and I hope that this will change over time
10:59 timotimo oh, yeah, working alone doesn't sound good, especially long-term
10:59 FROGGS only kinda alone, but still
10:59 timotimo mhm
11:00 FROGGS it's nice to have something to talk about the stuff that is going on, and I get that more in these channels that in person at work
11:00 FROGGS m: say num16
11:00 camelia rakudo-moar 127b3b: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤    num16 used at line 1␤␤»
11:00 FROGGS damn
11:01 timotimo right :|
11:03 dalek MoarVM: 94e6f6c | FROGGS++ | src/6model/reprs/C (4 files):
11:03 dalek MoarVM: remove (non-exitent) num16 from error message
11:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/94e6f6c5c7
11:13 FROGGS nebuchadnezzar: what are the next steps? do you need help with something?
11:35 Ven joined #moarvm
11:40 timotimo .o( did i miss something? )
11:46 Ven joined #moarvm
11:50 FROGGS timotimo: arm64 is okay now for rakudo, though it is not visible in the debian build logs yet
11:50 FROGGS timotimo: next up would be powerpc I think, which fails tests in rakudo's make test
11:52 timotimo ah!
11:52 timotimo that's what. cool :)
11:55 timotimo i think i might add valgrind client requests to the fixed size allocator
11:56 timotimo maybe that'll let me figure out why my fsa cache makes things explode
11:56 FROGGS and moarvm builds on mips*, though I have no clue if nqp or rakudo does (somehow I doubt it)
11:56 FROGGS sounds good :o)
11:57 timotimo have you ever used that stuff?
11:58 FROGGS no, but I guess you'll be able to hook a valgrind into a running process then?
12:00 timotimo nah, it's more like when valgrind is attached, you can give it additional info about stuff your program does with its memory
12:02 timotimo with the memory pools API you can say "we just allocated a piece of memory here, it belongs to the pool identified by this address" and "this pool has redzones on the left and right of size N" and "this piece of memory is now NOACCESS"
12:03 Ven_ joined #moarvm
12:03 lizmat http://www.iclarified.com/57138/apple-adds-arm-support-to-macos-sierra-kernel   # can't help but wonder what bugs will be shook out if my next MacBook has an  ARM  :-)
12:03 timotimo VALGRIND_DO_LEAK_CHECK: does a full memory leak check (like --leak-check=full) right now. This is useful for incrementally checking for leaks between arbitrary places in the program's execution. It has no return value.
12:05 timotimo VALGRIND_CREATE_BLOCK and VALGRIND_DISCARD. VALGRIND_CREATE_BLOCK takes an address, a number of bytes and a character string. The specified address range is then associated with that string. When Memcheck reports an invalid access to an address in the range, it will describe it in terms of this block rather than in terms of any other block it knows about. Note that the use of this macro does not actually
12:05 timotimo change the state of memory in any way -- it merely gives a name for the range.
12:05 timotimo ^- cool
12:05 timotimo oh! snap! i didn't even know valgrind offers a gdbserver with a bunch of useful commands
12:07 timotimo you can even manually make a piece of memory noaccess at an arbitrary point
12:07 timotimo and you can who_points_at <addr> [<len>], how cool is that
12:08 timotimo i don't seem to see a way to mark a region as "do not write here", though
12:10 FROGGS that's awesome!
12:11 FROGGS wouldnt it make sense to have a special debug build of moar adds names to memory reagions of th nursory/gen2 like 'class Foo / int8 $bar'?
12:12 FROGGS lizmat: would be interesting, aye :o)
12:12 timotimo --workaround-gcc296-bugs=<yes|no> [default: no]
12:12 timotimo When enabled, assume that reads and writes some small distance below the stack pointer are due to bugs in GCC 2.96, and does not report them.
12:12 timotimo fantastic
12:13 timotimo adding info to the nursery is a bit tricky because of the way we just discard stuff that hasn't been copied over; i'm not entirely sure yet how that maps to client requests
12:13 timotimo | | | | * e9b2cc9 - (origin/valgrind_support) WIP on valgrind annotations (1 year, 6 months ago) <Timo Paulssen>
12:13 timotimo ^- last time i looked into this
12:13 timotimo so, i'm probably smarter now than i was then ;)
12:15 Ven joined #moarvm
12:16 FROGGS :o)
12:17 FROGGS do you have gcc 2.96? I would not think so :o)
12:17 FROGGS # uname -a
12:17 FROGGS Linux froggs-Latitude-E6530 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:26:26 UTC 2016 ppc GNU/Linux
12:17 FROGGS ^----- this is a debian powerpcspe
12:17 FROGGS installing git now etc
12:18 * geekosaur hears the number of the Beast and shudders a bit
12:19 geekosaur (2.96 was a heinous Red Hat-ism)
12:19 timotimo oh?
12:20 timotimo the valgrind devs say implementing a read-only status for memory would be a significant development effort and would have a significant runtime impact
12:21 geekosaur yep
12:21 timotimo it would have been pretty cool to have for this one bug i'm experiencing in one of my (many, lousy) branches
12:22 geekosaur valgrind can't use CPU support, it has to emulate the CPU in software. implementing general read-only map support would indeed be painful both to develop and to run with
12:22 timotimo yeah, i guess
12:22 geekosaur as for gcc 2.96, there was no such thing officially. RH pulled a buggy unreleased post-2.95 revision and added more bugs to it
12:22 timotimo i wish there was a simple "append_only" thing for pages where it's readonly up until a certain position and can be written to after that and the position could only be increased
12:22 timotimo ah, i see
12:23 timotimo that's terrible :)
12:23 geekosaur then used it to compile the OS for one RH release, and the kernels for several subsequent releases
12:23 timotimo ;(
12:23 geekosaur the gcc folks were close to issuing death threats because they kept having to field bug reports that they couldn't do anything about
12:28 timotimo ;_;
12:28 timotimo that's the worst state of affairs ever
12:34 timotimo i'm going to need to teach the FSA about the concept of a redzone
12:47 Ven joined #moarvm
13:01 Ven joined #moarvm
13:03 timotimo ==23331== HEAP SUMMARY:
13:03 timotimo ==23331==     in use at exit: 0 bytes in 0 blocks
13:11 timotimo ^- this means that my annotations for the fixed size allocator were correct :)
13:17 Ven_ joined #moarvm
13:20 timotimo redzone will be a bit fiddly
13:20 timotimo where do i add, where do i subtract ...
13:50 zakharyas joined #moarvm
13:50 Ven joined #moarvm
14:34 timotimo operator precedence just f'd me over
14:34 timotimo i was moving over alloc pos with this code:
14:35 timotimo al->size_classes[bin].alloc_pos += (bin + 1) << MVM_FSA_BIN_BITS + 2 * MVM_FSA_REDZONE_BYTES;
14:35 timotimo but << is a very loose operator ...
14:47 Ven_ joined #moarvm
14:48 dogbert17 joined #moarvm
16:01 Ven joined #moarvm
16:16 japhb .tell FROGGS num16 is supposed to be this: https://en.wikipedia.org/wiki/Half-precision_floating-point_format -- 'half' or 'binary16' FP format
16:16 yoleaux2 japhb: I'll pass your message to FROGGS.
16:16 yoleaux2 09:11Z <nine> japhb: I guess exporting is the way to go but I'm not sure that would work right now. Alternatively one could copy the imported types from MY:: to GLOBAL:: in the top level module. Right now you won't find them in MY:: but that would just shorten the copy loop :)
16:20 FROGGS japhb: ohh, interesting
16:20 yoleaux2 16:16Z <japhb> FROGGS: num16 is supposed to be this: https://en.wikipedia.org/wiki/Half-precision_floating-point_format -- 'half' or 'binary16' FP format
16:21 japhb .tell nine Hmmm, thank you re: My:: --> GLOBAL:: hint.
16:21 yoleaux2 japhb: I'll pass your message to nine.
16:33 * FROGGS build moarvm on mips64el now
16:34 FROGGS is building*
17:32 Ven joined #moarvm
17:33 dalek MoarVM: 96d74e0 | timotimo++ | / (3 files):
17:33 dalek MoarVM: let the fixedsizealloc tell valgrind what's what.
17:33 dalek MoarVM:
17:33 dalek MoarVM: includes a redzone (forbidden bytes) between FSA allocations
17:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/96d74e0c80
17:33 timotimo ^- requires you to configure with --valgrind
17:33 timotimo and also requires you to actually run the moar binary through valgrind
17:46 travis-ci joined #moarvm
17:46 travis-ci MoarVM build failed. Timo Paulssen 'let the fixedsizealloc tell valgrind what's what.
17:46 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/169940964 https://github.com/MoarVM/MoarVM/compare/94e6f6c5c7ed...96d74e0c80bc
17:46 travis-ci left #moarvm
17:49 timotimo hmpf. the valgrind support didn't help with my sso stuff :(
17:51 nebuchadnezzar FROGGS: sorry, I'm discovering Valencia and Barcelona (in addition to the http://2016.opennebulaconf.com)
17:51 Ven joined #moarvm
17:51 FROGGS nebuchadnezzar: ohh, enjoy it! :o)
17:52 nebuchadnezzar thanks
17:52 nebuchadnezzar I warned domi about it
17:53 nwc10 timotimo: there doesn't seem to be anything that defines VALGRIND_MAKE_MEM_DEFINED
17:54 timotimo oh, didn't i put that in?
17:54 nwc10 if you did, I can't find it with `git grep VALGRIND_MAKE_MEM_DEFINED`
17:54 timotimo must have forgotten to actually push it
17:55 dalek MoarVM: 82628a5 | timotimo++ | src/memdebug.h:
17:55 dalek MoarVM: add back MAKE_MEM_DEFINED which somehow got lost
17:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/82628a5c73
17:56 nwc10 oops. :-)
17:56 nwc10 yes, MoarVM now builds for me
17:57 timotimo phew.
17:58 timotimo Memcheck: mc_main.c:5525 (vgMemCheck_is_valid_aligned_word): Assertion 'VG_IS_WORD_ALIGNED(a)' failed.
17:58 timotimo i wonder what i'm doing to cause that?
17:59 timotimo maybe the redzone has to be like 8 bytes?
18:11 travis-ci joined #moarvm
18:11 travis-ci MoarVM build errored. Timo Paulssen 'add back MAKE_MEM_DEFINED which somehow got lost'
18:11 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/169944402 https://github.com/MoarVM/MoarVM/compare/96d74e0c80bc...82628a5c735b
18:11 travis-ci left #moarvm
18:25 timotimo W: Failed to fetch http://downloads-distro.mongodb.org/repo/debian-sysvinit/dists/dist/10gen/i18n/Translation-en_US  Unable to connect to downloads-distro.mongodb.org:http:
18:43 cygx joined #moarvm
18:45 cygx got a segfault while playing around with re-exporting symbols, in particular https://github.com/cygx/p6-physics-gr/blob/master/lib/Physics/GR.pm
18:45 cygx segfault is at 0x0000000069bd41e9 in MVM_interp_run () at src/6model/sc.h:71
18:45 cygx 71          return sc_idx > 0 ? tc->instance->all_scs[sc_idx]->sc : NULL;
18:45 cygx I failed to come up with a minimal test case
19:02 cygx it's re-exporting &unit-matri that makes it explode, for whatever reason
19:02 cygx *&unit-matrix
19:02 Ven joined #moarvm
19:17 domidumont joined #moarvm
19:36 Ven joined #moarvm
19:52 Ven joined #moarvm
20:22 Ven joined #moarvm
20:40 zakharyas joined #moarvm
23:04 geekosaur joined #moarvm
23:17 dogbert17 joined #moarvm
23:37 timotimo oh, did i mention i was able to fix the little FSA cache
23:38 timotimo thanks to valgrind pointing me at the right address after i put in the redzone
23:52 diakopter timotimo++

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