00:14 lizmat joined
dalek arVM: aeef781 | TimToady++ | src/6model/reprs/NFA.c:
use continue consistently instead of break

Probably doesn't help the C optimizer, but the intent is clearer.		 01:20
arVM: 9603db0 | TimToady++ | src/6model/reprs/NFA.c:
fix tab damage
01:22 colomon joined 01:28 travis-ci joined
travis-ci MoarVM build passed. TimToady 'fix tab damage' 01:28
travis-ci.org/MoarVM/MoarVM/builds/42150849 github.com/MoarVM/MoarVM/compare/4...03db0a55af
01:28 travis-ci left
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 01:42
dalek arVM: f94d036 | (Timo Paulssen)++ | src/profiler/ (3 files):
[profiler] count allocs in spesh'd/jitted frames separately
 02:33
02:40 jimmy_ joined 02:47 ilbot3 joined 04:16 zakharyas joined 08:00 FROGGS joined 08:27 kjs_ joined 09:44 zakharyas joined 10:25 kjs_ joined 10:38 daxim joined 12:28 brrt joined 12:59 JimmyZ joined 13:17 zakharyas joined 13:39 zakharyas joined
dalek arVM: f420a8f | (Timo Paulssen)++ | src/spesh/optimize.c:
can turn a bunch of can_s ops into can ops instead.

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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!