Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-11-26

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

All times shown according to UTC.

Time Nick Message
00:14 lizmat joined #moarvm
01:20 dalek MoarVM: aeef781 | TimToady++ | src/6model/reprs/NFA.c:
01:20 dalek MoarVM: use continue consistently instead of break
01:20 dalek MoarVM:
01:20 dalek MoarVM: Probably doesn't help the C optimizer, but the intent is clearer.
01:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/aeef7810ac
01:20 dalek MoarVM: 9603db0 | TimToady++ | src/6model/reprs/NFA.c:
01:20 dalek MoarVM: fix tab damage
01:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9603db0a55
01:22 colomon joined #moarvm
01:28 travis-ci joined #moarvm
01:28 travis-ci MoarVM build passed. TimToady 'fix tab damage'
01:28 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/42150849 https://github.com/MoarVM/MoarVM/compare/4d71a93b814c...9603db0a55af
01:28 travis-ci left #moarvm
01:42 timotimo weird. i only very occasionally get allocations in spesh'd and in jitted frames, mostly it's either all in spesh or all in jit
02:33 dalek MoarVM: f94d036 | (Timo Paulssen)++ | src/profiler/ (3 files):
02:33 dalek MoarVM: [profiler] count allocs in spesh'd/jitted frames separately
02:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f94d036188
02:40 jimmy_ joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:16 zakharyas joined #moarvm
08:00 FROGGS joined #moarvm
08:27 kjs_ joined #moarvm
09:44 zakharyas joined #moarvm
10:25 kjs_ joined #moarvm
10:38 daxim joined #moarvm
12:28 brrt joined #moarvm
12:59 JimmyZ joined #moarvm
13:17 zakharyas joined #moarvm
13:39 zakharyas joined #moarvm
13:55 dalek MoarVM: f420a8f | (Timo Paulssen)++ | src/spesh/optimize.c:
13:55 dalek MoarVM: can turn a bunch of can_s ops into can ops instead.
13:55 dalek MoarVM:
13:55 dalek MoarVM: doing can at spesh-time is still not working properly.
13:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f420a8f779
14:05 dalek MoarVM: 94372f4 | (Timo Paulssen)++ | src/profiler/log. (2 files):
14:05 dalek MoarVM: prevent arbitrarily many allocation counts for same object
14:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/94372f4486
14:16 hoelzro joined #moarvm
14:19 travis-ci joined #moarvm
14:19 travis-ci MoarVM build errored. Timo Paulssen 'prevent arbitrarily many allocation counts for same object'
14:19 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/42198616 https://github.com/MoarVM/MoarVM/compare/f420a8f779f2...94372f4486ac
14:19 travis-ci left #moarvm
14:19 timotimo uh oh
14:19 timotimo oh, the clang build just stalled for 10 minutes compiling interp.c?
14:19 timotimo but i didn't change anything there?
14:32 zakharyas joined #moarvm
14:53 timotimo brrt: got a suggestion what i could have a look at next? :)
14:54 brrt have access to a mac?
14:54 brrt :-)
14:54 timotimo nope
14:54 timotimo don't even want to touch that memory bug with a ten foot pole
14:55 timotimo it scares me a lot
14:55 brrt and it doesn't happen with linux/clang?
14:55 brrt does anything weird happen under ASAN?
14:55 timotimo don't think so, but i could try
14:55 brrt please do
14:55 brrt :-)
14:55 timotimo yeah, let's run a full spec test with asan
15:00 [Coke] timotimo: I'm now getting memory errors on osx/parrot also. have fun! ;)
15:00 timotimo oh lord
15:00 timotimo so ... how do i tell moar to use clang?
15:02 brrt perl Configure.pl --cc=clang --ld=clang
15:02 timotimo thanks
15:02 brrt and be patient
15:02 brrt clang is ... not fast
15:02 timotimo with asan or without?
15:04 timotimo make: *** No rule to make target '3rdparty/uthash.h', needed by 'src/main.o'.  Stop.
15:04 timotimo ?!?
15:04 timotimo oh, heh.
15:05 timotimo so many warnings >_<
15:05 brrt oh yes, with asan
15:05 brrt perl Configure.pl --cc=clang --ld=clang --asan
15:05 brrt should do it
15:05 timotimo i added --debug=3 and --prefix=../install
15:15 brrt in the vein of drudgery but thankful work, any help on removing clang build warnings is appreciated
15:17 * timotimo joins #clang to yell at some developers
15:18 brrt don't do that :-) they'll just point at the C specs to you
15:18 timotimo haha
15:18 brrt and call you a lousy developer for daring to use gcc :-P
15:18 timotimo yeah, it's very common for people who have been abused to carry the abuse forward
15:19 brrt but yeah, clang is slow, and verbose, and whiny
15:19 brrt and it may yet provide insight :-)
15:19 brrt (and it is also the default compiler for mac os x)
15:20 JimmyZ and freebsd
15:20 timotimo All tests successful.
15:20 brrt and freebsd soon
15:20 timotimo aaaaand i'm out o/-
15:20 brrt :-) that's good news at least
15:21 timotimo i agree
16:10 TimToady yes, I observed the long hang on interp.c with mac/clang last week, when my friend was compiling perl 6
16:11 TimToady obviously they've got some O() of higher order going when compiling large routines
16:12 TimToady either that, or they just chew up too much memory
16:12 TimToady but my bet is on the algorithm
16:16 timotimo weird; on my machine moarvm actually compiled somewhat quickly
16:18 TimToady his might've been an older machine
16:19 TimToady but we were definitely about to panic when it finally finished
16:19 brrt hmmm
16:19 TimToady then, of course, we ran into the memory bug, so I ended up aiming him at the jvm version instead to play with
16:19 brrt strange that this works in this
16:20 brrt euh, strange that such an issue exists
16:20 brrt happen to know if your friend has os x yosemite installed or the older version?
16:21 TimToady dunno
16:22 brrt hmmm
16:39 [Coke] moar non-jit completely borked on osx's daily run.
16:42 TimToady .oO(Apple: tormenting implementors on behalf of the company...)
16:44 timotimo ;_;
17:25 hoelzro when I'm loading a precomp'd module A that loads B, should B.pm.moarvm be loaded? or should B's symbols all already be present in A.pm.moarvm?
17:41 TimToady the latter would be an available optimization only if B were considered immutable, meseemeth
17:41 TimToady and we consider local modules to be mutable, but officially installed ones immutable
17:42 hoelzro makes sense
17:42 hoelzro I'm just noticing that loadbytecode is being called for B.pm, but not ModuleLoader.nqp
17:42 hoelzro so I'm wondering if that has something to do with the odd precomp behavior we've been seeing
17:43 jnthn hoelzro: We always load B.pm.moarvm too
17:43 hoelzro jnthn: that's consistent with what I'm seeing
17:44 * TimToady has his brane still mostly in NFAland
17:44 hoelzro but the merge_globals in ModuleLoader.nqp isn't being called on A + B
17:44 hoelzro I'm wondering if that's related to the problem
17:45 TimToady and thinking the NFA engine needs to say how far it got both for optimizing rematches as well as for implementing <*abbreviatable>
17:45 jnthn TimToady: The "how far it got" thing plays into an opt I'd been pondering where, in the absence of captures, we just skip over must fo the imperative code in a regex
17:46 TimToady that's what I was referrin' to
17:46 jnthn Oh...
17:46 jnthn :)
17:46 TimToady but recording that info has some overhead
17:49 jnthn Well, my bigger problem was actually figuring out where to stick it too
17:51 timotimo <*abbreviatable> will cause code-gen to ignore capture creation etc?
17:53 TimToady well, since it starts with punctuation, it wouldn't capture without help anyway
17:54 TimToady <foo=*abbrev> would presumably capture what actually matched
17:54 TimToady internal captures would not be accessible unless you named the outer assertion
17:55 jnthn I can't actually remember what <*...> is precisely spec'd as
17:55 jnthn It was in my "yeah, not gonna be 6.0 unless somebody shows up with a patch" list, though.
17:55 jnthn Looks like somebody is considering it. ;)
17:56 TimToady it always succeeds with whatever prefix matched
17:56 jnthn Does it have to be followed by a literal?
17:56 TimToady for a literal, one can fake with a | ab | abb | abbr ...
17:56 jnthn Ah, so no, it doesn't :)
17:56 TimToady but it's specced to not limit to literals
17:57 TimToady but it's right in the bailiwick for the nfa engine
17:57 TimToady which already does precisely what it needs, but then throws away the info on how much actually matched
17:57 TimToady so I think it *would* be limited to what the nfa engine can do
17:59 TimToady the proper thing is probably to assume that the final fate (or lack thereof) is the only offset of interest most of the time
17:59 TimToady and if we have to backtrack on fates, we just force a rematch instead of optimizing
17:59 TimToady otherwise we have to associate an offset with each fate, and sort it along with, which is heavyish
17:59 TimToady especially since most fates are just thrown away
18:02 * TimToady wonders how often parsing the setting actually backtracks on fates...
18:02 jnthn Yeah, I think I did some stats on how often we take the first match and it was a lot of the time
18:02 jnthn though it was ages ago so I don't remember too well
18:02 jnthn Was comparing before/after we had LTM in place for it
18:02 TimToady longlit will only improve that number
18:03 jnthn Cool
18:03 TimToady (I suspect)
18:03 jnthn Any measurable improvement observed?
18:03 TimToady well, it's not really about performance, but correctness
18:03 TimToady or maybe "correctness"
18:03 TimToady depending on how correct the spec is
18:03 TimToady I was mostly just trying to avoid giving away the farm on performance
18:04 TimToady did you get a chance to look at the XXX in jvm?
18:04 TimToady or were you asking about taking-the-first-entry-ness?
18:04 TimToady didn't measure that
18:05 TimToady probably not terribly significant, since taking the wrong fate probably results in a misparse, as far as longlit is concerned, unless the wrong parse knows enough to backtrack to the more specific parse
18:06 TimToady longlit is more about removing wtfs
18:06 jnthn No, didn't get chance to look yet :(
18:06 TimToady well, the lazy use of longlit entries ameliorates some of the hurt of allocating 200 entries
18:06 TimToady at least it doesn't have to initialize all of them every time now
18:07 jnthn Teaching a course I didn't do before just days after longhaul flight has been kinda time-consuming and exhausing...
18:07 jnthn Went well, though.
18:07 TimToady but I know parsing the setting needs at least 102 entries, so 100 isn't enough
18:07 jnthn Hm...can we not hang a re-usable array off the tc?
18:07 TimToady no rush, it's just I don't know enough Java to get it to stage0 right
18:07 jnthn Like I did in Moar for the rest of the fates...
18:07 TimToady I tried, but feyled stage0
18:08 jnthn Hm, can you remember how it blew up?
18:08 jnthn I'm...a little surprised at the blow-up...
18:08 TimToady couldn't parse nqpmo
18:08 jnthn Oh. Odd.
18:08 jnthn I was imagining some kinda class incompatible exception mighta happened.
18:08 jnthn But that woulda been odd too
18:08 TimToady could be
18:12 jnthn OK. I'll have to reproduce it and see :)
18:13 TimToady doubtless it'll just work for you :)
18:14 TimToady but it was something harder than just a realclean on my linux box
18:15 TimToady it was like on the first 'has' declaration in nqpmo that it misparsed
18:16 TimToady does give a stack trace at that point, but I couldn't glean anything useful from it
18:17 TimToady afk &
18:26 jnthn TimToady: Grr...my first patch Just Worked..
18:26 FROGGS joined #moarvm
18:29 jnthn TimToady: https://gist.github.com/jnthn/5741f26b0f02143181e8 works for me...can you try it, to see if it exhibts the same issue as whatever you tried?
18:56 TimToady well, I was trying ArrayList<Integer>, so that's a difference
18:59 TimToady btw, it occurs to me that the way we return fates in nqp-m is non-reentrant, unless something I don't see in there is cloning the fates per nfa invocation
19:01 TimToady but it seems like something must be cloning, or we'd get far more failures than we do, since you wouldn't be able to re-use tc->fates in any subrule, not just a recursive one...
19:20 hoelzro ok, I found something interesting with precomp: https://github.com/rakudo/rakudo/blob/nom/src/Perl6/World.nqp#L361
19:21 hoelzro the current global context is not being provided to load_module
19:21 hoelzro so it never merges symbols in from precomp
19:21 hoelzro that doesn't seem correct to me
19:21 hoelzro or am I wrong here?
19:28 TimToady jnthn: patch works here, but doesn't seem to run any faster
19:29 TimToady but I'm not running a pristine setup here, so several grains of salt are in order
19:42 TimToady oh, I see where the fates are cloned now
19:50 jnthn Yeah, we do clone 'em
19:50 jnthn Well, or push 'em to a fresh array iirc
19:50 jnthn and in an alternation we push them onto the bastack
19:51 jnthn uh, bstack
19:51 jnthn ok, if the patch works I'll commit it
19:51 TimToady but the fates are still handled in an inferior run loop, which could be potentially problematic
19:51 TimToady at least for protos
19:51 jnthn Inferior run loop?
19:51 jnthn Moar doesn't have those except for callback from C land...
19:52 TimToady src/QRegex/Cursor.nqp:326
19:52 TimToady alts go to teh bstack though
19:52 jnthn hoelzro: That's just a perfectly ordinary method call
19:52 jnthn oops
19:52 jnthn TimToady: ^^
19:53 hoelzro jnthn: the method call is fine, but I think it's missing the GLOBALish parameter
19:53 jnthn It's just looping over the alternatives in NQP code
19:53 TimToady which can invoke an inferior run loop
19:53 jnthn ?
19:53 jnthn We never re-enter the NFA, though...
19:53 TimToady a regex can have a closure
19:53 jnthn I think I must be missing something
19:53 TimToady but we're just calling the subrule
19:54 jnthn I mean, to me an inferior runloop means that we have two interpreters on the C stack...
19:54 jnthn hoelzro: Yes, that was me answering a TimToady++ question, not yours ;)
19:54 TimToady I guess we're in nqpland
19:54 jnthn hoelzro: The answer to yours is rather simpler, thankfully
19:54 hoelzro ah, ok =)
19:54 hoelzro namely? =)
19:54 TimToady so I guess it's okay
19:54 jnthn hoelzro: We serialize the GLOBALish that the symbols are merged into
19:55 jnthn hoelzro: So you don't need to repeat the work.
19:55 jnthn It only needs doing once.
19:55 hoelzro I see
19:55 jnthn Same with all importing.
19:55 hoelzro I thought I'd found the bug =(
19:55 jnthn About GLOBALish
19:55 jnthn It's actually in UNIT
19:55 jnthn In fact, you can understand everything in terms of module loading and symbol handling in that way
19:56 jnthn The module loader has a dynamic, $*MAIN iirc
19:56 jnthn When we load a module, this dynvar is set
19:56 TimToady does precomp make any assumptions about the immutability of a local module?
19:56 jnthn To the UNIT lexical scope
19:56 jnthn TimToady: You'll need to be a bit more specific on "immutability" here
19:57 jnthn TimToady: I tend to see precomp as a cache
19:57 TimToady if you precompile with a 'use' of a local module, and then someone edits that
19:57 jnthn If you change the source of the module or the source of one of its dependencies, you invalidate the cache
19:57 TimToady okay
19:57 jnthn It's just that we don't actually handle that invalidation automatically yet
19:57 jnthn We just detect it happened
19:57 jnthn And tell the user "nope, this one is out of date"
19:57 jnthn We kay pre-comps on the SHA-1 hash of their source code.
19:58 jnthn It works pretty well for Git, so... :)
19:58 TimToady for known immutables, we lock it into the cache permanently
19:58 TimToady *we can
19:58 TimToady if the identity is sufficient to identify an immutable
19:59 jnthn True.
19:59 TimToady wild cards need not apply :)
19:59 TimToady just making sure our multi-versioning story stays straight...
19:59 jnthn *nod*
21:33 brrt joined #moarvm
22:33 brrt left #moarvm
23:05 woolfy joined #moarvm
23:09 lizmat joined #moarvm
23:13 kjs_ joined #moarvm
23:21 woolfy left #moarvm

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