00:00 stmuk joined 00:16 Ven_ joined 00:18 FROGGS joined 00:22 retupmoca joined 00:50 FROGGS joined 01:53 tokuhiro_ joined 02:23 flussence joined 02:38 psch joined 02:45 hoelzro joined 02:48 ilbot3 joined 04:20 colomon joined 06:37 domidumont joined 06:54 domidumont joined
nwc10 good *, #moarvm 07:18
07:46 FROGGS joined 07:54 brrt joined
brrt \o #moarvm 07:54
nwc10 o/ brrt
brrt \o nwc10 08:00
brrt is pondering writing a jit log parser in perl6 08:01
which would be my first real perl6 program
JimmyZ brrt: Did you try lua's showing jit code through gdb? P 08:30
08:33 zakharyas joined
brrt JimmyZ - you mean the luajit gdb integration 08:43
didn't do that, now
no
shoud do that once
would be nice
but i'm bikeshedding enough as it is
it's a nice-to-have 08:44
JimmyZ yeah. 08:47
09:34 kjs_ joined 10:06 zakharyas joined
jnthn morning o/ 10:06
stmuk Lee on another channel has pointed me at
github.com/MoarVM/MoarVM/pull/287 10:07
brrt morning jnthn
jnthn stmuk: In theory, github.com/MoarVM/MoarVM/commit/b2...c4c8a103c1 got rid of that warning 10:09
stmuk: Does it still show up on latest? 10:10
stmuk I'll check
jnthn Thanks :) 10:11
nwc10 that was very off-topic for *that* channel. It's supposed to be about beer. Or was it buffy. I forget
stmuk jnthn: sorry those warnings are fixed .. although there are "warning: assigning to 'MVMuint8 *" in 4 files which I shall try and poke sue to fix 10:12
jnthn stmuk: Yes, those warnings want fixing (and don't show up on my regular compiler). Thanks. 10:15
The || vs && prec one drove me nuts. 10:16
stmuk I always found it ironic gcc had warnings compiling itself - a case of "do as I say not how I do" 10:18
dalek arVM: 902e1ba | (Francois Perrad)++ | src/io/ (2 files):
remove unreachable code
 10:25
arVM: 19757bd | jnthn++ | src/io/ (2 files):
Merge pull request #270 from fperrad/lint_20150925_io

remove unreachable code
arVM: d4a20f0 | jnthn++ | src/strings/decode_stream.c:
Re-use, rather than repeat, \r\n grapheme code.
 10:35
arVM: c2908ce | peschwa++ | src/ (3 files):
Make MVMMultiCache container aware.

This patch allows caching of Rakudo multi candidates that dispatch differently with identical types but different rwness. I'm not completely sure that nothing has to be done for MVM_multi_cache_find_spesh, but I haven't come across any breakage without adding something there. Of course that doesn't necessarily show there isn't any.		 10:39
arVM: bdb61f2 | peschwa++ | src/6model/reprs/MVMMultiCache.c:
Fix missing space after conjunction.
 10:40
arVM: 8dbc50e | jnthn++ | src/ (2 files):
Move constant, and explain it better.
 10:44
jnthn Odd, my seemingly innocent perf refactor of psch++'s multi cache causes explosions... 10:59
jnthn gets out the debugger 11:00
ah, duh 11:02
nwc10 "insufficient coffee"?
jnthn Pretty much :) 11:04
dalek arVM: aa14aa0 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
Simplify/optimize multi cache rwness bits.

Move code into paths that already did various checks, and make use of a NativeRef always being writable to avoid the checks on that.		 11:10
jnthn Darn, fixing the spesh/multi cache thing will be a little tricky. 11:21
But really needs doing, not only 'cus it's wrong now, but because it affects our ability to inline things as simple as $i++ 11:22
timotimo this is about all kinds of inlining with lexfers involved? 12:07
jnthn No
I mean $i++ on a simple Int 12:08
Not even natives involved
timotimo oh
fair enough
jnthn Because the multi cache now needs the "yes it's rw" mark set
nwc10 ilmari: lunch, er ASAN
timotimo OK, fair enough
jnthn is building a patch at the moment 12:09
yay, it actually fixes my test caes
Not bad for first time
timotimo first time's the charm 12:10
jnthn Doesn't fix inlining of $i++ though
m-prof: my $i = 1; while $i++ < 1000000 { } 12:11
camelia: help
camelia jnthn: Usage: <(nqp-js|debug-cat|prof-m|p5-to-p6|rakudo-MOAR|pugs|star-m|nqp-parrot|std|nqp-moarvm|nqp-jvm|niecza|rakudo-moar|rakudo-jvm|star-j|nqp-q|rakudo|nrP|Pnr|nPr|p6|j|Prn|r-m|m|M|nqp-j|r|nr|nqp|rm|sj|p56|r-j|star|rn|n|r-jvm|rPn|rnP|sm|nqp-mvm|perl6|nqp-p|P|rj|nom|nqp-m)(?^::\s(?!OUTPUT))
..$perl6_program>
jnthn oh
prof-m: my $i = 1; while $i++ < 1000000 { }
camelia prof-m 273e89: OUTPUTĀ«Writing profiler output to /tmp/mprof.htmlā¤Ā»
.. Prof: p.p6c.org/1a1537f
timotimo can you only speshed, not jitted, eh?
jnthn OK, that's not a regression
timotimo and also not inlined
jnthn yeah, wonder why no jit 12:12
Going to spectest this patch, anyways
I think psch++ will be glad I didn't send him off for a spesh baptism of fire to write this one :) 12:13
timotimo: If you fancy some (probably easy) JIT work, you could fix the two new guard ops :)
timotimo ah
jnthn uh, s/fix/add JIT for/
timotimo perhaps the jit isn't happy about isrwcont?
jnthn Maybe that too
timotimo that's exactly it
(on my machine at least)
jnthn Oh, but with what I just did
We can spesh that away ;)
timotimo oh, neato 12:14
jnthn My patch adds a "we know it's an rw cont" fact flat
fag
flag
gah
timotimo do you think it'll ever have an isrwcont and not have that flag? in that case i'll add it to the jit anyway
jnthn Could happen
timotimo 'k
probably very easy to write anyway
jnthn Though in the patch I'll prolly push soon I assumed that we're unlikely to get polymorphism around rwness 12:15
timotimo that's fair
jnthn (Mostly 'cus it made the patch easier :))
(Though only a little) 12:16
jnthn still likes the spesh code, having just come back to it for the first time in quite a while
I'm kinda looking forward to next year, when I can take my "chase down/fix language semantics issues" hat off for a bit and wear my optimization/robustness one. :) 12:17
timotimo this'll want me to write an iscont_rw function in containers.c and that'll want me to figure out how to read that bit from an object 12:18
jnthn Don't think you need a function
You do what iscont does
And then if it is, you look up the ->can_store function from the container spec 12:19
And just call that
timotimo ah, thought so
jnthn Guess it's easy enough to call things through function pointers in the JIT
timotimo yup 12:20
but i'll still write it as a C function
i don't think it's performance-critical enough to turn that into jit code to get rid of that single indirection 12:21
jnthn I guess not, if we can optimize it out
Please then make the interpreter also use that function
So we reduce the number of code paths doing the same thing
The C compiler will probably go and inline it for us
timotimo just making sure here, iscont_rw is about more than just nativeref? 12:22
jnthn Yes
timotimo good
if (contspec && contspec->can_store(cont)), right? 12:23
jnthn aye
uh, tc, cont
timotimo tc, yeah
pseudocode anyway :)
you know, i could have just looked at isrwcont in inter.pc 12:25
interp.c
it seems like i'm still a bit foggy from sleepyness?
dalek arVM: b86c7b9 | jnthn++ | / (6 files):
Add new spesh guard ops for rw containers.
 12:26
arVM: 480dc8c | jnthn++ | src/ (7 files):
Add a spesh flag for "known rw container".
arVM: 0181385 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
Use spesh rw cont flag when searching multi cache.
jnthn sleepyness will do that...
timotimo the meds i have make me feel a bit better, but i think they're purely symptomatic 12:28
um, after pulling your latest patches, do i have to rebuild nqp&rakudo? because that code from earlier gives me a segfault now 12:31
jnthn Yes 12:32
timotimo good
jnthn Turns out that the spesh routines in the perl6 dynops end up with the spesh op IDs compile in
timotimo oh!
yeah, that can happen 12:33
jnthn We should fix that, so there's an API to look up the spesh op IDs late bound
timotimo mhm
jnthn Otherwise we'll have a binary compat problem down the line
timotimo we could open a github issue about that and give it to someone new-ish
if you want me to, i'll write it 12:35
jnthn Go for it :) 12:37
timotimo hm, currently the isrwcont survives instead of turning into a guard 12:38
ah
there's a guardrwconc in the <unit> frame, though
timotimo gets crackin'
jnthn If the fact is there, you can rely on it 12:39
As in, it should just go away, not turn into a guard
timotimo er, yeah
jnthn Much like deconts do
timotimo well, it's a deconted_concrete_rw flag, but the isrwcont is on the arg itself, not its decont
maybe that's why it doesn't trigger? 12:41
jnthn I only mean that we handle unrequired deconts by deleting them (well, replace with set), and that's what we'll want to do with isrwcont
dalek arVM: e0c7ae4 | timotimo++ | src/ (3 files):
isrwcont can now be jit'd
timotimo oh, so you mean there's just no code in place yet to optimize away the isrwcont 12:42
got'cha
jnthn Correct
We couldn't do anything for it before now
But with the flag I added I think we now can :)
Just turn it into an iconst iff we have that flag.
(If we don't have the flag, it's a "don't know" and we'll have to leave it as it is) 12:43
timotimo right, it'll become an const_i, that'll go into the assertparamcheck and the assertparamcheck will disappear 12:44
jnthn Right
And take the const_i with it
timotimo yeah 12:46
and all will be well
jnthn Yeah 12:47
Wonder what then keeps the ++ from inlining
timotimo there's a branch that adds a bunch of debugging spam 12:48
it's literally called something with "spam" in its name
debugspam_inlining
my assembly is a tiny bit shaky, so i'm hoping the spec tests will exercise this sufficiently 13:05
jnthn: i get "all tests successfull", but do you have a piece of code that'd explode if the guards were wrong? 13:12
i suppose i'll just push the patch and see if someone complains 13:14
dalek arVM: 4f5c97c | timotimo++ | src/jit/ (2 files):
implement guardrwtype and guardrwconc in the jit
 13:15
jnthn timotimo: Well, maybe that by-trait.t one would 13:16
timotimo t/spec/S06-multi/by-trait.t ................................... ok
:)
i've already had a little patch to spesh iscont and iscont_*, but it caused breakage :( 13:18
psch S06-multi/by-trait.t doesn't have any native rw specific tests currently though, if that could matter
jnthn psch: Yes, the native types behavior is the only thing currently keeping me from considering the RT resolved 13:19
psch: Why does the multi dispatcher throw X::Parameter::RW?
psch jnthn: because otherwise it would throw Multi::NoMatch 13:20
jnthn I don't think it should. I've just spent a while debugging the multi dispatcher to see why it was getting as far as dispatching
Thinking it was doing so
Yes, it should throw a Multi::NoMatch!
psch jnthn: then roast is wrong
m: ++"x"
camelia rakudo-moar f3e960: OUTPUTĀ«Parameter '$a' expected a writable container, but got Str valueā¤ in block <unit> at /tmp/kDAMdHbsym:1ā¤ā¤Ā»
jnthn Agree :)
timotimo the naming of "deconted_concrete_rw" bugs me; it sounds like "deconts to something that is rw", but it's really "a rw container that contains something concrete"
jnthn timotimo: Feel free to change it to something clearer :)
timotimo nah, i've got enough to do for starts :)
psch jnthn: that also means Parameter::RW only happens on non-multis, which makes it a bit over-specific, on a hunch 13:21
jnthn psch: Also fixing this will get us an error that shows the signature, which will be much clearer than the "where's that mysterious $a come from"
timotimo oh! yes!!
psch yeah, that i definitely agree with
jnthn psch: You could say the same about all signature binding exceptions that overlap with things multi dispatch cares for, though. 13:22
Anyway, lunch is ready here...so I'll go eat and bbi30 :)
timotimo only 30 minutes? you don't rush a good meal, jnthn :P 13:23
psch hm, i guess my Parameter::RW annoyance mostly hinges on "multis are different than sub", in the end 13:24
m: sub f(Int $) { }; f Str
camelia rakudo-moar f3e960: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/eC2y3GlKT0ā¤Calling f(Str) will never work with declared signature (Int)ā¤at /tmp/eC2y3GlKT0:1ā¤------> sub f(Int $) { }; āf Strā¤Ā»
psch m: multi f(Int $) { }; multi f(Num $) { }; f Str
camelia rakudo-moar f3e960: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/p6hqKpfugYā¤Calling f(Str) will never work with any of these multi signatures:ā¤ (Int) ā¤ (Num)ā¤at /tmp/p6hqKpfugY:1ā¤------> multi f(Int $) { }; multi f(Num $) { }; āf Strā¤Ā»
psch vOv 13:25
well, if roast is wrong about Parameter::RW on multis that's fine with me
nwc10 ilmari: ^^ hint from jnthn :-) 13:28
ilmari nwc10: I just finished my lunch :-P 13:31
nwc10 \o/
timotimo very good, isrwcont and assertparamcheck get thrown out
nwc10 good news: I've acchieved POETS 13:32
timotimo now it's getart, takedispatcher, p6oget_o, wval, wval, add_I, assign, return_o
nwc10 bad news: because I keep being in the office early.
timotimo getarg_o, not getart
13:33 vendethiel joined
timotimo jnthn: it looks like postfix:<++> is inlined this time! 13:33
YES! 13:34
dalek arVM: 5f007a9 | timotimo++ | src/spesh/optimize.c:
we can spesh isrwcont into a const now.
timotimo i'm doing a before/after timing of that simple benchmark now 13:37
In total, 423 call frames were entered and exited by the profiled code. Inlining eliminated the need to create 1999586 call frames (that's 99.98%). 13:38
lizmat timotimo: that's for natives ? 13:39
timotimo no
lizmat ah, too bad :-) 13:40
timotimo oh wow
lizmat but would it make ++ on natives faster nonetheless ?
timotimo 11.98user 0.02system 0:12.00elapsed 100%CPU (0avgtext+0avgdata 75384maxresident)k
36.80user 0.06system 0:36.85elapsed 100%CPU (0avgtext+0avgdata 75664maxresident)k
lizmat 3x faster, it seems ?
timotimo just about
okay, here's timings for the native int case 13:41
43.76user 0.05system 0:43.79elapsed 100%CPU (0avgtext+0avgdata 75712maxresident)k 13:42
^- old-ish moar
43.79user 0.07system 0:43.84elapsed 100%CPU (0avgtext+0avgdata 75672maxresident)k 13:46
^- latest moar
yeah, still doesn't inline postfix:<++> there 13:48
it allocates ALL the IntLexRefs, too
huh, the code for postfix:<++> looks kind of ugly inside of spesh 13:50
it uses lexicals for that stuff, rather than registers 13:51
so the code is bindlex $a to hold the first argument
bindlex 0 to $b to initialize it
take dispatcher
getlex $a
decont an int from $a 13:52
bind the value of that into $b
getlex $a (again)
getlex $b (why?! whhhyyyyy)
load a 1
add that 1 to the $b we just got
assign the result into $a
get $b 13:53
return $b
it also has 4 deopt points, one before each getlex 13:54
using ++$i instead of $i++ with a native $i gives a crazy speed-up. 13:56
lizmat: ^
lizmat will keep that in mind
timotimo ah :)
bon appetit on your breakfast
JimmyZ getlex is the most thing that can't be inlined, iirc 13:57
13:57 zakharyas joined
JimmyZ that's why lex=> local branch want to be merged? 13:57
timotimo yeah, we really want lex=>local 13:58
interesting. ++$i actually doesn't inline prefix:<++> either
i was wrong about the speedup, too 13:59
there is actually no speedup at all
jnthn back 14:02
timotimo urgh, our codegen ... 14:03
getlex r2(1), lex(idx=0,outers=0,$a)
getlex r3(1), lex(idx=0,outers=0,$a)
jnthn We need to be careful when optimizing such things 14:04
(For memory model reasons)
timotimo r2 gets used to assign the result of add_i-ing into, r3 gets used as the source for adding 1 to
the only thing between bindlex and getlex for $a is takedispatcher
but according to the profile, the unit costs 80.8% exclusive time 14:05
how the hell does it spend all that time? getlexref_i perhaps?? 14:06
jnthn For the native case?
Probably. getlexref_i isn't that cheap
timotimo aye, and prefix:<++>
ah?
well, then that'd be a problem 14:07
jnthn Not really, given the assumption is that at some point spesh'll rip a bunch of them out.
timotimo hm. fair enough.
jnthn Though the design is such that we can optimize their taking too 14:08
14:08 Ven joined
psch m: multi f(Int $x) { "Int" }; multi f(Int $x is rw) { "rwInt" }; multi f(int $x is rw) { "rwint" }; say f 5 # this seems to want another moar rev bump 14:09
camelia rakudo-moar cc1ba3: OUTPUTĀ«rwintā¤Ā»
psch hrm, maybe it wants more, actually
'cause latest moar does the same locally. otoh, with --gen-moar i get a bunch of failures in by-trait.t 14:10
jnthn ?
I bumped NQP_REVISION/MOAR_REVISION?
psch jnthn: with --gen-moar i was 12 commits behind HEAD on moar 14:11
jnthn ah
I'm looking into the native rw stuff a bit at the moment
psch oh, but moar HEAD SEGVs again in by-trait.t ..?
timotimo hum. with my inlining debugspam i get output for unit trying to inline infix:Ā«<Ā»
but nothing for prefix:<++>
that's weird.
jnthn psch: Not for me 14:13
psch: Did you rebuild your Rakudo too? 14:14
psch yeah, i'm pretty sure i did
i'll git clean
timotimo OK, the attempt to get prefix:<++> fails after looking for the multiple dispatch cache 14:18
psch welp, must've messed something up somewhere along the way. Configure.pl with --gen-{moar,nqp} works
timotimo as in, MVM_multi_cache_find_spesh returns 0
psch: not pointing a finger at you :P 14:19
psch timotimo: uh, i was talking about the SEGV i got... :) 14:20
as in, "messed up [building rakudo] somewhere"
timotimo no, i mean ... because cache_find_spesh
psch oh
yeah i didn't touch that :P
timotimo :)
jnthn timotimo: Odd, the patches I did shoulda been sufficient for us to find it
timotimo shall i put debugspam into that function? 14:21
psch running spectest against "no Parameter::RW from find_best_dispatchee", which also has some simplification of the rwness checking...
increment.t i already know needs adjusting 14:22
jnthn psch: Gah, we're both working on the same code then :/ 14:23
jnthn also just did that
psch: Go for updating the tests, anyway
timotimo jnthn: the reason why we bail for (what i assume must be) prefix:<++> is that arg 0 doesn't have the "known_type" flag set 14:29
jnthn o.O
Odd
timotimo: Wait, native or? 14:30
timotimo gimme a bit
yeah, that's native
jnthn yeah, we don't understand native refs enough in spesh yet
timotimo ah, it's that easy?
jnthn Yeah
psch jnthn: i've demoted $rwness_mismatch to an int, 'cause that's enough there
jnthn psch: OK, cool
timotimo wouldn't we just have to put an entry into facts.c to create_facts for getlexref_*? 14:31
psch not sure how much of an impact that has, but it probably adds up eventually...
jnthn aye :) 14:34
timotimo: I don't know. The truth is I don't want to have to think about it.
timotimo: I want to ignore it until next year.
I've too much on my plate.
timotimo understood 14:35
jnthn However we do it, we have to work out how we'll eliminate them post-inline 14:36
timotimo indeed
psch huh 14:37
sort_dispatchees confuses me 14:38
unless isnull { sort }
so if we have sorted candidates, sort them again..?
but apparently that's where the candidate order confusion with Range.new came from anyway, so it's probably fine as-is... 14:39
jnthn huh, it's if nqp::isnull(@candidates) { 14:40
oh, sort_dispatchees
psch m: *..42i
camelia rakudo-moar 041875: OUTPUTĀ«WARNINGS:ā¤Useless use of ".." in expression "*..42i" in sink context (line 1)ā¤Complex objects are not valid endpoints for Rangesā¤ in block <unit> at /tmp/PJ7c3XmOgQ:1ā¤ā¤Ā»
psch yeah, i had changed sort_dispatchees to if isnull, but if i do that Range.new doesn't throw that anymore
because the Complex candidates moves out of the tie-group that has the Whatever candidate
sort_dispatchees is only called in World, from Actions.comp_unit 14:41
well, no idea... "don't touch it, it works!" vOv
jnthn ;) 14:42
It's possible there actually is a problem in Range also and this bug hides it
psch gist.github.com/peschwa/c17cb7ebb9692f5783d5 is the candidate ordering i get when i change sort_dispatchees to if isnull 14:43
i don't readily see why the Complex candidate would move out of the 2nd group...
i assume Match:D is in the 3rd group because of defcon, and the other two are there because no nominal 14:44
well, except compunit stuff and we don't resort correctly... 14:45
m: multi f() { }; multi f($) { }; my $dispordr = nqp::getattr(nqp::decont(&f), Routine, '$!dispatch_order'); say $dispordr.HOW.name($dispordr) 14:47
camelia rakudo-moar 041875: OUTPUTĀ«VMNullā¤Ā»
psch that's because we don't actually sort_dispatchees_internal on a proto that hasn't been invoked yet when we sort_dispatchees
timotimo jnthn: the cache_find_spesh is expecting a container (which it has inspected the lexref type to be) to also have decont_concrete and decont_typeobj flags set; i should probably set the exact same flags that guard deconted_concrete_rw thing has?
14:50 tokuhiro_ joined
timotimo it's kind of weird to say that a lexref_i would decont to something concrete 14:51
and to something which we know the type of
because what do i set the type to %) 14:52
it'd feel righter if the cache find could recognize native containers 15:01
nwc10 this is very strange. If I build Moar with ASAN, the setting build SEGVs 15:48
if I use the same gcc, but build debugging and do the setting under valgrind, no SEGV
(there is at least 1 unit byte passed to write() - so again, I assume that our MAST generator is skipping a byte or two for alignment and it's not initialised ever) 15:49
jnthn nwc10: SEGVs giving a nice ASAN hint of what went wrong?
nwc10 no, a SEGV that looks like a NULL pointer dereference
jnthn ah 15:50
15:50 Ven joined
hoelzro o/ #moarvm 16:02
nwc10 \o hoelzro
getting anywhere useful with ASAN?
hoelzro o/ nwc10
yes! I managed to produce a bunch of failures with my branch last night =) 16:03
nwc10 er, "yay", I think 16:05
hoelzro heh 16:06
well, it's progress
16:08 kjs_ joined 16:12 Ven joined
timotimo hm, i wonder if findnotcclass and friends need to be updated for the new \r\n stuff? 16:22
jnthn Not afaik 16:24
They've long dealt with synthetics 16:25
The only change wsa that \r\n became a synthetic
timotimo mhm 16:26
because json::fast got confused - i'll have to write a proper test case
jnthn Well, does it use nqp::ord? 16:28
timotimo argh 16:30
yes, it does
i thought i had implemented nom-ws as findnotcclass
jnthn Yeah, avoid nqp::ord
timotimo well, nqp::ordat in this case
jnthn Or more to the point
Avoid it if you are expecting to talk about chars :) 16:31
timotimo github.com/timo/json_fast/blob/mas...pm#L50-L59 - what would this look like in our shiny grapheme-clean world? 16:33
jnthn timotimo: hm, not sure why that bit would be an issue 16:35
timotimo hm, ok, could even be that that's not the problem 16:36
the symptom is "cannot parse an object starting in
"
with a newline there
so the thing that goes there gets grabbed with an nqp::substr($text, $pos, 1) and nqp::ordat($text, $pos) is known to not be 32, 10, 13 or 9 16:41
so i shall output a bit more stuff to debug
lizmat nqp::ordat is suspect, maybe, in the current NFG world? 16:42
it returns the codepoint of the base char, no?
so that would be 13 for both \r and \r\n
jnthn Aye 16:43
timotimo that should be fine
jnthn Though I don't see anything immediately in the code that would get bitten by it
timotimo and then substr should give me the synthetic of the next thing
buildy buildy buildy a new rakudo 16:48
16:50 pyrimidine joined 16:51 Ven joined
timotimo i can't reproduce that bug locally, grml 16:54
jnthn r: sub s_s(*%n) { %n>>.say }; s_s(|{:assoc<list>},:assoc<left>); 17:11
camelia rakudo-moar 019a7f: OUTPUTĀ«listā¤Ā»
..rakudo-jvm f0c6a0: OUTPUTĀ«leftā¤Ā»
timotimo argh! :) 17:12
jnthn Turns out one of the xmas RTs that was reported as a nextwith bug boils down to that 17:14
So, 2 become 1
17:14 Ven joined
nwc10 will Christmas be before or after valentine's day? :-( 17:17
jnthn 6.v is quite a long way off :P 17:19
We're down to 47 xmas RTs by now
And 42 days until Dec 25th :) 17:21
nwc10 6*9
and I think it *is* 54 days until Jan 6th
but my brain is tired
hoelzro is there a tag for xmas? 17:22
jnthn Ther's a meta-ticket 17:23
rt.perl.org/Ticket/Display.html?id=123766
hoelzro thanks jnthn 17:25
17:50 colomon joined 17:54 tokuhiro_ joined 17:57 kjs_ joined 18:48 kjs_ joined 19:41 zakharyas joined 20:17 FROGGS joined
nwc10 timotimo: there's something very strange about commit 4f5c97c15d03f9 - implement guardrwtype and guardrwconc in the jit 20:21
gcc 4.9 ASAN doesn't like it
but gcc 4.9 without ASAN is OK, even running under valgrind 20:22
specifically, with ASAN, the setting build will SEGV (just a NULL pointer dereference) unless I comment out the MVM_OP_sp_guardrwtype stuff
but tests will still fail due to the MVM_OP_sp_guardrwconc stuff
if I set MVM_JIT_DISABLE all is happy 20:23
so I have no idea why the assembler stuff in the JIT messes with ASAN annotated code
but valgrind doesn't spot any problems
timotimo nwc10: uh oh, let me have a look 20:40
oh, hm, asan only does malloc and free? 20:42
hoelzro timotimo: I take it you need it for calloc/realloc? 20:43
timotimo whereas valgrind does every single allocation?
huh?
no, i'm just wondering why my JIT stuff explodes
hoelzro timotimo: I was wondering what else you would need it for
timotimo perhaps invoking the magical brrt would help?
hoelzro nevermind me
timotimo another possibility would be to sanitize data access
nwc10: well, one thing that it does is call functions, so maybe there's something wrong with the way it does that? 20:45
nwc10 I really don't know. 20:47
timotimo can you give me some output to look at?
nwc10 I have to rebuild
and it's a stack tracek mostly with ??
timotimo sorry; in that case i can rebuild, too
ah, of course. because jit :(
so, brrt, is my patch to introduce the new guard functions wrong? i didn't make it carefully enough i suspect 20:48
20:52 zakharyas joined
timotimo oh, nwc10, you don't happen to have stumbled over the problem with asan where it'll give a nonzero exit code if there were any leaks at all, eh? 20:54
that seems to be new
nwc10 no, not met that
21:16 tokuhiro_ joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!