00:17 cognominal joined 01:17 FROGGS_ joined 04:49 lizmat joined 04:55 woolfy joined
TimToady however, MVM_SPESH_INLINE_DISABLE=1 causes my gist to succeed rather than fail on the flip 05:10
sergot hi o/ 06:24
06:59 FROGGS[mobile] joined 07:31 klaas-janstol joined 07:41 zakharyas joined 09:19 klaas-janstol joined 09:20 brrt joined
brrt \o 09:20
nwc10 brrt: commit 0c127ce530205b1fe2025095c5f5f03eca66ae23 introduces ASAN barf 09:21
brrt oh rly :-)
very nice
lets see what that commit is
nwc10 paste.scsys.co.uk/409096
I think it's trying to malloc(-8)
oh, maybe I can't count
it's minus soemthing 09:22
brrt hmm.. i expected something was fishy about that commit
oh, blimey 09:23
that's ... just dumb 09:24
malloc(num_args - 6) 09:25
unconditional, too 09:26
dalek arVM/moar-jit: 1e11c5b | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Make malloc of on_stack args buffer conditional

  nwc10++ pointed out that this causes a malloc of silly
propportions as the size_t argument to malloc is interpreted as unsigned.
When fewer than 6 arguments are present, it is never necessary to allocate a buffer at all.		 09:39
brrt nwc10++
i've another for you coming in the next commit
:-)
or better yet 09:40
can you tell me how i'd link with ASAN 09:41
nwc10 which version of gcc do you have?
brrt let me see 09:44
4.8.3
i also have clang, vesion 3.4
nwc10 I think either will do 09:45
certainly, clang should
you need -fsanitize=address in both the C compiler flags, and (I think) the "linker"
FROGGS[mobile] would be nice to switch that on by Configure.pl 09:46
nwc10 I'm running Configure.pl as perl Configure.pl --prefix=/home/nicholas/Sandpit/moar-san-jit --cc=ccache\ /usr/local/gcc49/bin/gcc\ -fsanitize=address\ -Wl,-rpath=/usr/local/gcc49/lib64 --ld=/usr/local/gcc49/bin/gcc\ -Wl,-rpath=/usr/local/gcc49/lib64\ -fsanitize=address --debug --optimize=0 --enable-jit
but the rpath dance is needed because the compiler is not in a standard location
I think it's needed for both "CC" and "LD" because sometimes "CC" is used for linking
but I might have cargo-culted it
brrt ok 09:47
FROGGS[mobile] don't you have to -lsomething too?
brrt it would be nice to put that in Configure.pl indeed 09:48
nwc10 I'm explicitly not going to do that (because I don't have time/sanity/headspace)
brrt i have all these :-) 09:49
i suspect putting them in CFLAGS / LDFLAGS would work, too 09:50
09:55 japhb joined
brrt bbiab 09:55
09:58 klaas-janstol joined
jnthn Afternoon, #moarvm 10:29
nwc10 heresy!
jnthn :P
FROGGS_ hi jnthn 10:48
jnthn o/ 10:49
jnthn is happy to report that from this evening he'll have time to help with Moar/Perl 6 things again. :) 10:50
FROGGS_ \o/
10:50 brrt joined
FROGGS_ jnthn will fix all the spesh/inline bugs /o/ 10:51
:P
jnthn Ć„hnejs...we have spesh/inline bugs? 10:52
brrt we have bugs, that's for sure
jnthn Very well; I'll accepted bug reports - preferably nicely golfed - this evening. :)
FROGGS_ <TimToady> however, MVM_SPESH_INLINE_DISABLE=1 causes my gist to succeed rather than fail on the flip 10:53
this one: gist.github.com/anonymous/0873fd7dd630a9deb6f2
jnthn ok
FROGGS_ jnthn: as MoarVM issues?
brrt some of these bugs are probably my own, though :-)
jnthn Well, can't hurt to put them there, but let me know on here which ones are most blocking stuff. 10:54
brrt can't seem to to get asan to work on his machine :-( 10:55
nwc10 if you have enough spare CPU and disk, build gcc 4.9 from source 10:56
brrt or maybe i can, and there's just nothing it can do 10:58
yes, i suppose i do have these :-)
i'm a lousy programmer, that's for sure 11:08
carlin wishes he was as half as good a programmer as brrt++ 11:11
brrt i think you'll manage that :-) 11:12
carlin looking at what you've done on moar-jit, I don't think so :) 11:14
if that's what you consider lousy... I should fine a new hobby
*find
brrt i'm flattered :-) but apparantly, the thing is bug-infested as well, so i'm not so easily pleased with myself 11:15
and certainly don't find a new hobby 11:16
we need all perl6 people we can get :-)
FROGGS_ jnthn: you got three new issues now 11:20
github.com/MoarVM/MoarVM/issues/117 is the most important I think 11:21
brrt i somehow doubt that the issue that asan finds is as serious as i think it is 11:24
ehm, as serious as ASAN thinks it is 11:28
nwc10 carlin: we'll help you get better, if you want to join in here 11:31
jnthn FROGGS_: For #117, don't suppose you can include the error? 11:40
FROGGS_ jnthn: I can, sec 11:42
jnthn thx 11:43
brrt clang tends to complain about a lot of things gcc doesn't care about
FROGGS_ jnthn: I commented 11:44
gcc really is DWIM, and clang is the opposite :o)
jnthn WAT? :) 11:45
FROGGS_ that's why you usually have portability issues when you develop on gcc only
brrt DWIM FTW
FROGGS_ hehe, yeah
jnthn m: say 'FTW'.flip 11:48
camelia rakudo-moar 2bc8f6: OUTPUTĀ«WTFā¤Ā»
brrt such true 11:49
nwc10 if you really want bondage and discipline, try xlc on AIX
FROGGS_ ohh, bondage does not sound bad at all 11:51
or perhaps it sounds bad? like really bad?
nwc10 www.imdb.com/title/tt0093779/quotes...=qt0482737 11:52
paraphrased to "AIX is pain, Highness. Anyone who says differently is an IBM employee"
although, to be fair, AIX make is sane. HP UX is, um, special
brrt clang is annoyingly slow in comparison to gcc 12:05
nwc10 at what? compiling programs? or bootstrapping its own install?
brrt compiling programs 12:06
...... fts 12:08
i'll do it with varargs, then
12:21 jnap joined 12:27 jnap joined, klaas-janstol joined
brrt wel, vargs definitilty didn't make it go away, for some reason 12:50
jnthn bbi1h 13:04
brrt ah, i see the problem with the vargs solution now 13:20
... darn 13:22
brrt is not having any luck today, it seems 13:41
FROGGS[mobile] jnthn: I Made my on bugfixathon from friday to sunday and I guess I closed about 15 tickets...
jnthn: would you like to join such a session at some point? 13:42
13:57 btyler joined 14:04 lizmat joined
brrt cdn.meme.li/instances/500x/52847844.jpg 14:05
FROGGS[mobile] hehe 14:10
brrt is running tests right now and seeing if it helps at all 14:11
btw, looking at create in src/core/interp.c, i think it's possible we've done boxing wrong after all 14:12
but i'd like to have jnthn++'s sage advice on that still
14:14 woolfy joined
dalek arVM/moar-jit: e0e0d1d | (Bart Wiegmans)++ | src/jit/ (4 files):
Add write barrier for sp_p6obind_s

This fixes a heap corruption error in MoarVM that puzzled me for the better part of a weekend. Obviously, strings need write barriers, too.		 14:16
FROGGS[mobile] I really should ask what write barriers are for 14:21
nwc10 "avoiding headdesk" - I thought that it was obvious :-) 14:22
In this context, I can't actually answer helpfully 14:23
brrt which,strings requiring them or what they are for
write barriers are for ensuring that whenever an 'old' object gains a reference to a 'young' object (which will be moved if it lives), the GC can update the reference to the moved object 14:24
and yes, this should've been obvious; i've just taken a very very very long time to find the right place to look at :-) 14:28
jnthn lols at the brrtmeme 14:34
Also, brrt++ for fixing stuff 14:35
timotimo brrt: is this it?
brrt this is the bug that prevented me from building nqp 14:36
now nqp and rakudo run again
(and their testsuites, too)
i've had limited luck adding asan as a Configure.pl option
also, \o jnthn 14:39
hope you had a great weekend, you were missed by me at least :-)
lizmat jnthn brrt nwc10 o/
this just on #perl6
timotimo oh: my \jnthn;#)
lizmat multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort)
segfaults, but only if the subs are called in this order 14:40
and they're *both* called
and it doesn't seem to be spesh related
thought this would be a nice, short example 14:41
brrt weird, though
timotimo word.
lizmat breakfast& 14:42
jnthn Multi-cache issue, maybe? 14:47
2 invocations woudln't be enough for spesh to have kicked in.
14:51 jnap joined
brrt also, asan is really angry at the way i use call arg arrays in src/jit/graph.c, but i have no idea what'd be wrong with it 15:01
FROGGS_ brrt: about OP(create)... that means that stuff in registers is MVMROOTed by default, at least in interp.c... 15:02
and it means that initialize might allocate, which would explain the MVMROOT(tc, box, ... be have seen before
(in box_s)
brrt uhuh 15:03
but... if we assign the box to the register before initializing, we might not need that?
FROGGS_ if that was the return value, yes
brrt ok, i'll note it 15:04
FROGGS_ yes, also in box_i we could strip some code when we assign the allocated thing to GET_REG(cur_op, 0).o 15:05
though, we'd need to pass GET_REG(cur_op, 0).o around, which will get slightly unreadable for set_int for example 15:06
dalek arVM/moar-jit: 149c07e | (Bart Wiegmans)++ | Configure.pl:
Added Configure support for ASAN

ASAN (code.google.com/p/address-sanitizer/) is a very useful tool for finding all sorts of memory errors in C programs. If you have it installed (with recent clang or gcc) then you can now get it using the --asan flag.		 15:21
brrt nb, this works better with GCC than clang in my experience, although it /should/ work with clang 15:22
FROGGS_ brrt++ # build-sanitizer
brrt it's multi cache issue 15:40
timotimo is that the problem with mordre? 15:46
that actually sounds kinda "right" 15:47
15:49 klaas-janstol joined
brrt well, ehm, lets just say that the object that should come from that is not null, not vmnull, and not a pointer 15:55
and right now i'm wondering why rakudo say doesn't compile to nqp::say 15:56
jnthn Needs to be aware of $*OUT. Needs to call .gist on arguments unless they are already strings. Needs to handle multiple arguments. 15:57
say in NQP is actually a wrapper fwiw 15:58
brrt bbafter lunch 15:59
dinner
jnthn nom well o/
brrt tnx o/ 16:00
[Coke] dd 16:17
er, ww 16:18
16:29 woolfy left 17:15 brrt joined 17:29 lizmat joined 17:42 lizmat joined, vendethiel joined
brrt i'm having no luck 17:50
FROGGS_ :(
brrt perl6 has an impossible amount of multi dispatches just before it runs anything 17:51
well, i'm having some luck, i fixed bugs that perplexed me for a week - and they were simple, too
but not with the multi cache thing
oh 17:55
num_args is 0
(huh, that shouldn't happen?)
what are acceptable values for arg_flags? 17:58
ok, i'm at the breaking function that returns such a weird pointer 17:59
FROGGS_ look at MoarVM/src/core/callsite.h:5: MVM_CALLSITE_ARG_OBJ = 1 18:00
brrt aha 18:03
it looks suspiciously like num_args should not be num_pos 18:07
ok, so i know why lizmat++'s bug happens 18:21
the multi in question has no positionals and only a single named argument 18:22
the fact that it has a named argument is sufficient reason for the multi cache to keep looking
jnthn I can see where this might be going... :)
brrt but, it uses the number of positionals as a total argument count and an index to the arity cache
in fact, it uses the num_args - 1 as the index to the arity cache 18:23
jnthn Yeah, the arity zero candidate logic needs a tweak I guess
brrt because, at some point in the past, somebody said 'zero arity, we already have a slot for that'
18:23 lizmat joined
TimToady I sense a disturbance in the force... 18:24
brrt anyway, you're reading - quite possibly - somewhere in the body and interpreting that as a cache object 18:25
how to fix that, i'm not entirely sure, because it'd simultaneously mean fixing the add logic (otherwise you'll return the wrong frame) 18:26
in fact it seems that this is about the question 'how do named args contribute to arity'
jnthn Well, they don't; the cache already has some stuff relating to nameds handling.
brrt very well 18:27
then the correct response on any zero-positional callsite should be NULL, i think
jnthn Oh, no; it's got a special slot for a zero-arity solution
foo() should be cacheable 18:28
It's just that something, somehow, goes wrong when there's a foo(:name)
brrt and what about foo(:fort)
18:29 jnap joined
brrt well, in this case, it tries to look at arity_caches[-1] 18:31
jnthn Yeah, it should never make it that far
if (num_args == 0 && !has_nameds) 18:32
return cache->zero_arity;
I think that's the nice at fault
I think it wants to be more like 18:33
if (num_args == 0)
return has_nameds ? NULL : cache->zero_arity;
brrt seems legit
ok, that works :-) 18:38
gist.github.com/bdw/69c277a8aed133cfe6ba please review, and if ok, i'll commit and push it 18:39
jnthn seems legit, though the comment ("bail if") isn't quite true; it's more like "only add if there are no nameds" 18:40
brrt will change 18:41
FROGGS_ ohh I love bug fixes these days 18:43
TimToady
.oO(Perl 6 is so wonderful you can even do pair programming by yourself...)
 18:44
FROGGS_ *g*
dalek arVM: 2748afd | (Bart Wiegmans)++ | src/6model/reprs/MVMMultiCache.c:
Fix issue with zero-arity named multis

Named arguments do not count for the arity in the MVMMultiCache, however they do not fit in the
  'zero arity' slot either. Consequently, when supplied
with a callsite without positionals but with named arguments, the cache algorithm searched for matches in a negative offset of the arity entries array. This fixes that by refusing to deal with such callsites.		 18:50
brrt ugh, i should have said it in the commit message, but lizmat++ for the excellent bug report and jnthn++ for the solution :-) 18:51
lizmat Ven actually found the problem
brrt well, ven++ then too :-) 18:53
brrt will be feeding gooslings for a bit 18:55
jnthn: are extops ever invokish? 18:56
timotimo they could conceivably invoke i think 18:58
as in: i think i could build one that is and therefor it should be accounted for
jnthn brrt: Yes, they can be, but I think they may be rare enough we can get away with not JITting them 19:30
timotimo do we store which extops are invokish and which aren't? 19:31
because not jitting any frames that have extops in them will bite us when we're in perl6 code, i believe 19:32
jnthn timotimo: I was planning to add something so extops can declare their JIT-ability and even participate in spesh. 19:35
timotimo ah, good
20:05 cognominal joined, Ven joined 20:17 brrt joined
jnthn Oh dear. 20:20
src\strings\unicode.c(42938) : error C2065: 'entry' : undeclared identifier
src\strings\unicode.c(42938) : fatal error C1003: error count exceeds 100; stopping compilation
brrt hmm i see 20:21
clang also complains heavily about src\strings\unicode.c 20:22
jnthn FROGGS_: About 339d547c... 20:23
First, it breaks the build on Windows. Second, it edits a generated file...so next time we re-generate it we'll lose the changes
The top of the file is all like
/* DO NOT MODIFY THIS FILE! YOU WILL LOSE YOUR CHANGES! 20:24
This file is generated by ucd2c.pl from the Unicode database.
:)
Ven jnthn: well, he did commit the changes to ucd2c.pl, didn't he ?
brrt jnthn - do you happen to know if moar-jit is still broken on windows?
jnthn ohh, uh
Yeah, sorry, my git log command still had the filename in there.. 20:25
brrt: Not yet; can test later today
brrt please do
:-)
or tomorrow
FROGGS_ jnthn: ohh, sorry for the windows breakage :/ 20:26
brrt should have really virtualised his hard disk by now, but hasn't because lazy / complex
jnthn FROGGS_: Think I got it fixed now. 20:27
brrt hmm.... it seems ext ops are a bit more involved than i had considered 20:47
FROGGS_ brrt: welome to Perl 6, that is the usual can of worms one trips into :o) 20:49
brrt so true 20:52
or rather i should say
hmm 20:54
20:55 klaas-janstol joined
brrt one part of it is easy - calling a function pointer with tc, with the cur_op pointing at something the function would undestand - i.e. its arguments - and the other part - dealing with jumpish, invokish, throwish things, that might be tricky 20:56
but, i think i've a solution
dalek arVM: 3c2d4aa | jnthn++ | / (2 files):
Fix MSVC build.
 20:57
brrt ok, i propose the following solution for invokish
ehm, not invokish, i mean extop 20:58
basically, during spesh codegen, annotate the extop nodes with the offsets into the spesh bytecode 20:59
20:59 klaas-janstol joined
brrt then, at runtime, temporarily push that offset into place (in *tc->interp_cur_op), so that the extop gets the 'right' context' 21:00
fwiw, i don't really think many of these ops will be invokish, as the extop-running code increments the cur op after calling the function, and that would be very annoying if invokish
(one could always write a 0 for that value, but i digress, and i suppose that'd have it's effects on the reading / grraph building too) 21:01
then, when the function returns, check if interp_cur_op still points to the same value we left it on, and if not, it was jumpish / invokish, it should not 21:02
if it was jumpish, then we should fall out to the interpreter, if not, we continue in the jit code 21:03
makes sense?
(i suppose we'll have to do throwish ops in the same way, but i'm not yet sure how throwing works in general) 21:04
i'm off for tonight 21:07
see you tomorrow!
o/
21:07 brrt left
jnthn brrt: Bad news, JIT is still explosive on Windows :( 21:19
21:29 lizmat joined
FROGGS_ jnthn: does it at least work when the jit is not enabled? 21:36
jnthn Didn't check; am working on one of the other bug reports at the moment.
FROGGS_ k 21:37
just asking because of merging jit into master
m: multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort) 21:43
camelia rakudo-moar 72d574: OUTPUTĀ«(signal )graou~ā¤Ā»
FROGGS_ okay, need to wait another 30mins 21:44
lizmat 6 'multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort)' 21:45
graou~
GRAOU!!!!!
works fine for me :-) 21:46
t/spec/S02-types/bag.t , test 118 started flapping for me 21:48
FROGGS_ hmm, not for me 21:49
jnthn On #116, latest is that it fails during a deopt of an OSR'd reify 21:54
FROGGS_ brrt also pasted this, maybe it is related: gist.github.com/bdw/e5b606499aa6435f7e72 22:20
gnight (it is QAST midnight already) 22:22
jnthn That's more an inefficiency (failed to toss instruction) than a bug. 22:24
afaict, anyways
22:52 hatseflats joined 23:05 carlin joined
dalek arVM: 986910e | jnthn++ | src/spesh/dump.c:
Fix spesh dump of num literals.
 23:22
arVM: dab88dc | jnthn++ | src/spesh/dump.c:
Spesh dumping of lexicals.
arVM: 93597b9 | jnthn++ | src/spesh/osr.c:
Cope better with a frame being re-OSR'd.

If this happened, the frame may have been resized already. The upshot of this is that we didn't do the "allocate zeroed and copy" sequence that ensures the environment is empty for the inlinees. Thus, old and bogus pointers could end up being grabbed from the previous OSRing. Fixing this clones #116.
23:28 klaas-janstol joined, lizmat joined
dalek arVM: b6a4250 | jnthn++ | src/spesh/osr.c:
Don't try OSR-ing if frame already hit limit.
 23:38
jnthn Well, that's one of the bugs down at least... 23:40
lizmat so did jit get merged (can't backlog at the moment) 23:42
?
jnthn no 23:44
I fixed a bug though. :)
lizmat ok, I wondered because I didn't see a branch in the above commit
jnthn Sure, the bug I just fixed wasn't JIT-related.
lizmat ah, ok :-) 23:45
jnthn Time for some rest...'night 23:55

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!