Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-15

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

All times shown according to UTC.

Time Nick Message
02:23 leedo perhaps related to FROGGS's last commit? https://gist.github.com/leedo/8c390fcbe47d5e2e5fd5
02:24 leedo (rebuilding to make sure i'm not crazy)
02:30 leedo ok, nuking my install dir seems to have fixed it
04:56 cognominal joined #moarvm
04:59 cognominal joined #moarvm
05:06 cognominal joined #moarvm
06:02 cognominal joined #moarvm
06:04 cognominal joined #moarvm
07:20 FROGGS joined #moarvm
08:27 zakharyas joined #moarvm
08:57 brrt joined #moarvm
09:08 flaviusb joined #moarvm
09:11 leont joined #moarvm
10:58 zakharyas joined #moarvm
11:07 jnthn joined #moarvm
11:24 leont joined #moarvm
12:24 rurban_ joined #moarvm
12:37 dalek MoarVM: a677430 | FROGGS++ | src/6model/reprs/P6int.c:
12:37 dalek MoarVM: include stdbool.h conditionally
12:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a677430d85
13:18 dalek MoarVM/line_based_coverage: d33795d | timotimo++ | src/ (2 files):
13:18 dalek MoarVM/line_based_coverage: dead-end for trying to get more lines covered
13:18 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/d33795da2b
13:18 dalek MoarVM/line_based_coverage: 27aa4c5 | timotimo++ | tools/parse_coverage_report.p6:
13:18 dalek MoarVM/line_based_coverage: add a simple coverage report to HTML tool
13:18 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/27aa4c5f40
13:19 dalek MoarVM/line_based_coverage_2: fb7373e | timotimo++ | / (11 files):
13:19 dalek MoarVM/line_based_coverage_2: first prototype of a per-line coverage reporter
13:19 dalek MoarVM/line_based_coverage_2: review: https://github.com/MoarVM/MoarVM/commit/fb7373e377
13:19 dalek MoarVM/line_based_coverage_2: 5608af6 | timotimo++ | / (6 files):
13:19 dalek MoarVM/line_based_coverage_2: add missing files, adjust op to not use spesh slot
13:20 timotimo (just a rebase to get rid of the "modified oplist from a branch and on master" problem)
13:20 dalek joined #moarvm
13:21 timotimo and now i'll teach that exporting tool about moar --dump | grep annotation:
13:22 timotimo which will remove a whole bunch of red lines that we can't ever turn green
14:00 pyrimidine joined #moarvm
15:02 zakharyas joined #moarvm
15:21 timotimo hey jnthn; it currently looks like each little piece of code in QASTOperationsMAST would have to do its own line number annotation handling (and they don't do it); maybe that wants to live in compile_op itself?
15:22 timotimo that's only really interesting for the core setting, but on the other hand, the core setting is the one place that we really want to have line-by-line coverage with
15:38 timotimo jnthn: i think i need a bit of guidance for this; i don't want to give every single mapper an extra argument for the $op.node, but add_core_moarop_mapping already discards everything but $op.op and $op.list
15:39 timotimo should i grab the return value of calling $moarop_mapper and putting that into an Annotated?
15:39 jnthn Well, the idea was that we only really annotated stmts nodes
15:40 jnthn or stmt
15:40 timotimo oh, hm.
15:40 timotimo i see the code in compile_all_the_stmts that puts the annotation in
15:40 jnthn Meaning multi-line statements would end up with an annotation of their start line
15:40 virtualsue joined #moarvm
15:40 jnthn The actual annotations you see in the bytecode, for the purposes of what you're doing, perhaps want to be interpreted as "this line and the next ones that aren't annotated"
15:40 timotimo could it be we're turning too many things into a sinlge stmt or stmts in the optimization phase?
15:42 timotimo that makes things ... uncomfortable :)
15:42 timotimo because in order to find lines to grey out i'm just grepping "annotated: " from the moar --dump
15:43 timotimo so now i'll have to differentiate between "this line doesn't show up, but it's between two annotations" and "this line never shows up anywhere"
15:43 timotimo alternatively ... i'm only looking for grey lines if a line doesn't show up with a "HIT" output from the coverage output
15:44 timotimo so if i make sure enough HIT lines show up for a single annotation ... that could work
15:44 timotimo do you think it'll be important to walk all annotations inside a BB or would it be enough to get the file/line number from the beginning of each BB?
15:48 timotimo i'll have to be extra careful about things like "is the inline bit set" and also only if the line of the latter BB is higher and has the same filename and ...
15:48 timotimo ugh
15:48 jnthn Well, if we're in a BB we should probably run it to completion
15:48 timotimo that's right
15:49 timotimo that part is clear; much more difficult is what exactly goes on between BBs
15:59 hoelzro good moarning #moarvm!
16:00 timotimo so perhaps the line number annotation op gets another parameter for "how many lines does this correspond to"
16:01 timotimo and i'll probably want to store up 4k or something of bytes before locking, writing, unlocking
16:07 jnthn timotimo: That could be one way to do it, yeah
16:07 timotimo jnthn: so, going through all annotations that exist for a given BB, yea or nay?
16:08 jnthn I think you'd have to go through the BB
16:08 jnthn Multiple statemetns can be in one BB
16:13 timotimo that's what i thought. OK!
16:13 timotimo luckily, the IP of the beginning of the linear_next BB has to be correct (if it's not inlined)
16:24 vytas joined #moarvm
17:10 rurban_ joined #moarvm
17:33 dalek MoarVM/line_based_coverage_2: 42e4b54 | timotimo++ | src/main.c:
17:33 dalek MoarVM/line_based_coverage_2: show MVM_COVERAGE_LOG in moar --help
17:33 dalek MoarVM/line_based_coverage_2: review: https://github.com/MoarVM/MoarVM/commit/42e4b5465f
17:33 dalek MoarVM/line_based_coverage_2: 3f0c647 | timotimo++ | tools/parse_coverage_report.p6:
17:33 dalek MoarVM/line_based_coverage_2: grey out lines that don't have annotations in the bytecode
17:33 dalek MoarVM/line_based_coverage_2: review: https://github.com/MoarVM/MoarVM/commit/3f0c647e88
18:21 timotimo jnthn: in order to have something like a bytecode annotation iterator, should i add a "next bytecode address" or "next annotation's address" field to MVMBytecodeAnnotation on top of the filename and line number fields?
18:31 zakharyas joined #moarvm
18:33 leont joined #moarvm
19:12 FROGGS joined #moarvm
19:24 Peter_R joined #moarvm
19:27 vendethiel joined #moarvm
19:45 geekosaur joined #moarvm
19:52 timotimo instead of dealing with file locking, i'll spread out file output into pid-numbered files and keep the "append" logic, as only a single process (in the same process namespace) can have a given pid at the same time
19:52 diakopter timotimo: see line number spectest breakage in #perl6
19:52 diakopter timotimo: I thought you hadn't merged it yet
19:52 diakopter oh now I see your messages there
19:52 diakopter *bloop*
20:09 timotimo going to log -971268454 lines
20:09 timotimo perfect!
21:17 bartolin_ joined #moarvm
21:18 patrickz joined #moarvm
21:19 bartolin_ I just dropped in to mention that MoarVM doesn't build on BSD currently: https://github.com/MoarVM/MoarVM/issues/311
21:21 * bartolin_ does not know C, so the suggested patch might be plainly wrong ...
21:21 bartolin_ but at least I was able to build with that patch
21:23 diakopter bartolin_: thanks for the contribution
21:23 diakopter it might break osx?
21:23 diakopter don't know
21:24 * geekosaur would suggest renaming the moar "fileno" instead, because there is no guarantee that fileno is also provided as a function
21:24 geekosaur (well, there is on fbsd, there is not in general. and traditional (non-gnu) stdio has fileno defined as a macro)
21:26 geekosaur I don't see a fileno function in libSystem.dylib on OS X
21:27 [Coke] TimToady: build now warns at "src/core/CompUnit/RepositoryRegistry.pm" line 204 of 308
21:27 [Coke] the $compunit there generates a useless...
21:29 bartolin_ geekosaur: ahh, that's interesting (traditional stdio having fileno defined as a macro). I googled for a while but wasn't able to get a clear picture
21:29 geekosaur you basically saw it in clang's error message :)
21:30 bartolin_ geekosaur: yes, but that was only my specific version of FreeBSD :-)
21:30 geekosaur fileno() macro gets turned into a field access through the (FILE *)
21:40 * jnthn hasn't really expected a macro to apply on the RHS of ->
21:41 jnthn Or did I misread the error?
21:41 jnthn No, I didn't. It really does try to macro that.
21:42 [Coke] jnthn: hey, can someone write an EBCIDIC to NFG converter? (not you, just wondering if someone who is excited about such a thing could)
21:42 [Coke] whoops, wrong window on the compunit thing.
21:42 geekosaur CPP macros are dumb
21:42 jnthn No kidding :)
21:42 geekosaur they do not know C
21:43 jnthn But yeah, a rename should deal with it
21:46 timotimo is getpid() crossplatform?
21:49 jnthn Doubt it
21:49 jnthn May have to be _getpid() for MSVC
21:51 timotimo the libuv docs use getpid() in a nexample, but i still thought i'd ask
21:52 timotimo ah, indeed, we have a getpid function in moar already
21:56 timotimo this code is .. roundabout %)
21:56 timotimo but it makes extra sure that the format string it gets from the environment is sane
21:56 timotimo so i think that's worth something
21:58 timotimo actually ...
21:58 timotimo why don't i write a function that takes a string pointer from the environment to give back a file descriptor ... and if there's a %d in there it sanitizes the input as a format string, substitutes the %d for the pid and uses that
21:58 timotimo that way we'd be able to have .pid.txt files for jit log, cross thread log, spesh log, ...
21:59 timotimo and the coverage log, too
22:04 patrickz Hey. I just installed moar (and nqp/rakudo/panda/some modules) with the executable stack bit turned off (linker option -z noexecstack). Stuff seems to work. Now I wonder, am I bound for failure? (Because there should be some reason for gcc to set that bit in the first place...)
22:04 patrickz gcc on linux that is
22:04 timotimo i don't think we try to execute anything on the stack. we only ever jump into the heap when we do JIT
22:04 timotimo noexecstack is a security feature, right?
22:05 timotimo it'd be swell if you could run "make spectest" (usually you want to set TEST_JOBS to number-of-processors + 1 or so) and see if it explodes due to trying to execute stuff on the stack
22:05 timotimo i suspect it won't. in that case it'd be cool if we had detection for how to set "noexecstack" on different OS/compiler combinations :)
22:05 patrickz it's a mark on exec files that signals the program might use the feature.
22:06 patrickz SELinux prevents execution of moar on that machine of my hoster thus the fiddling with this stuff...
22:08 geekosaur patrickz, as far as I know things default to exec-stack for historical reasons
22:09 geekosaur you can turn that off on the file and see if it works or segfaults
22:09 geekosaur (since most things should not actually require it at this point)
22:09 patrickz geekosaur: http://linux.die.net/man/8/execstack says the opposite
22:09 patrickz i.e. default to not turn that on except when finding gcc trampolines
22:11 geekosaur interesting
22:12 patrickz hm, it says "recent GCC versions" that might be the key...
22:12 geekosaur although I note it also sets it based on libraries
22:13 geekosaur so if the libs on the build system had execstack enabled, the executable would be so flagged
22:13 geekosaur but if the libs on the run system don't have execstack then the program doesn't actually need it
22:17 timotimo that's interesting. so whether or not stuff on the stack can be executed depends on what the IP is currently going through?
22:17 geekosaur ?\
22:17 geekosaur no, I am assuming a binary was copied between systems
22:17 patrickz hm. I currently run the spec suite on a system that prohibits execution of libraries with that bit set. Looking good so far.
22:17 patrickz nope
22:18 patrickz I also built on that system
22:18 geekosaur interesting
22:19 geekosaur ok, that doesn't make much sense then; probably have to dig into docs for specific library and toolchain versions for that system (or if you are lucky, for the OS release it's running --- note that you may need hosting provider specific docs)
22:19 patrickz it would make sense if that is an old gcc that defaults to "true" as you suspected or if there actually is some stack exec going on (which should make my spec run fail)
22:19 geekosaur also stack exec may only happen in unusual circumstances
22:20 geekosaur like "is native" functions with certain specific types, or something like that
22:20 geekosaur (in perl6 terms)
22:20 geekosaur basically it may allow for it but it's only a problem if it actually gets used, and perhaps nothing actually uses it yet
22:29 patrickz gcc 3.3 introduced automatic exec stack detection
22:34 patrickz 25 spec test failures.
22:35 patrickz I guess those are not related
22:35 timotimo the spec test is currently quite unhappy, yeah :(
22:40 jnthn Try make test also, which includes the NativeCall tests
22:47 timotimo ugh. ugh. ugh.
22:47 timotimo some of these line annotations i come up with make 0 sense
22:47 patrickz use-trace.t one failure callbacks.t no tests ran
22:50 jnthn That callbacks.t one is suspect
22:51 patrickz is nativecall using nested functions?
22:51 timotimo but ... why would dyncall build its callback handlers on the stack?
22:51 jnthn nested?
22:51 timotimo no, wait ...
22:52 timotimo in order to actually call stuff, does it jump into generated machine code?
22:52 jnthn patrickz: We delegate that stuff to dyncall or libffi
22:52 jnthn timotimo: Almost certainly for callbacks
22:53 patrickz if I understand correctly that exec stack stuff is basically only needed for callbacks to nested functions. GCC uses some exec stack stuff for those.
22:53 timotimo jnthn: did you get around to fixing the problem with strings starting with an invalid utf8 character in utf8-c8? i don't remember ...
22:53 jnthn timotimo: no
22:54 timotimo OK, so my memory isn't bad on that
22:56 jnthn 'night, #moarvm
22:56 timotimo gnite jnthn
22:57 patrickz good night
23:15 virtualsue joined #moarvm
23:17 timotimo HIT  gen/moar/m-CORE.sHIT  src/vm/moar/ModuleLoader.nqp  1
23:18 timotimo i don't actually know how i b0rk this.
23:19 timotimo ah, it's probably due to when some program crashes it doesn't flush that file descriptor
23:19 timotimo flush after every print? why, that's such a great idea! >_>
23:19 timotimo and, i'm sure, not slow at all
23:51 konobi joined #moarvm

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