Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-22

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

All times shown according to UTC.

Time Nick Message
00:17 cognominal joined #moarvm
01:17 FROGGS_ joined #moarvm
04:49 lizmat joined #moarvm
04:55 woolfy joined #moarvm
05:10 TimToady however, MVM_SPESH_INLINE_DISABLE=1 causes my gist to succeed rather than fail on the flip
06:24 sergot hi o/
06:59 FROGGS[mobile] joined #moarvm
07:31 klaas-janstol joined #moarvm
07:41 zakharyas joined #moarvm
09:19 klaas-janstol joined #moarvm
09:20 brrt joined #moarvm
09:20 brrt \o
09:21 nwc10 brrt: commit 0c127ce530205b1fe2025095c5f5f03eca66ae23 introduces ASAN barf
09:21 brrt oh rly :-)
09:21 brrt very nice
09:21 brrt lets see what that commit is
09:21 nwc10 http://paste.scsys.co.uk/409096
09:21 nwc10 I think it's trying to malloc(-8)
09:21 nwc10 oh, maybe I can't count
09:22 nwc10 it's minus soemthing
09:22 brrt hmm.. i expected something was fishy about that commit
09:23 brrt oh, blimey
09:24 brrt that's ... just dumb
09:25 brrt malloc(num_args - 6)
09:26 brrt unconditional, too
09:39 dalek MoarVM/moar-jit: 1e11c5b | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
09:39 dalek MoarVM/moar-jit: Make malloc of on_stack args buffer conditional
09:39 dalek MoarVM/moar-jit:
09:39 dalek MoarVM/moar-jit: nwc10++ pointed out that this causes a malloc of silly
09:39 dalek MoarVM/moar-jit: propportions as the size_t argument to malloc is interpreted
09:39 dalek MoarVM/moar-jit: as unsigned.
09:39 dalek MoarVM/moar-jit:
09:39 dalek MoarVM/moar-jit: When fewer than 6 arguments are present, it is never necessary
09:39 dalek MoarVM/moar-jit: to allocate a buffer at all.
09:39 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/1e11c5bbe9
09:39 brrt nwc10++
09:39 brrt i've another for you coming in the next commit
09:39 brrt :-)
09:40 brrt or better yet
09:41 brrt can you tell me how i'd link with ASAN
09:41 nwc10 which version of gcc do you have?
09:44 brrt let me see
09:44 brrt 4.8.3
09:44 brrt i also have clang, vesion 3.4
09:45 nwc10 I think either will do
09:45 nwc10 certainly, clang should
09:45 nwc10 you need -fsanitize=address in both the C compiler flags, and (I think) the "linker"
09:46 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
09:46 nwc10 but the rpath dance is needed because the compiler is not in a standard location
09:46 nwc10 I think it's needed for both "CC" and "LD" because sometimes "CC" is used for linking
09:46 nwc10 but I might have cargo-culted it
09:47 brrt ok
09:47 FROGGS[mobile] don't you have to -lsomething too?
09:48 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)
09:49 brrt i have all these :-)
09:50 brrt i suspect putting them in CFLAGS / LDFLAGS would work, too
09:55 japhb joined #moarvm
09:55 brrt bbiab
09:58 klaas-janstol joined #moarvm
10:29 jnthn Afternoon, #moarvm
10:29 nwc10 heresy!
10:29 jnthn :P
10:48 FROGGS_ hi jnthn
10:49 jnthn o/
10:50 * 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 #moarvm
10:51 FROGGS_ jnthn will fix all the spesh/inline bugs /o/
10:51 FROGGS_ :P
10:52 jnthn åhnejs...we have spesh/inline bugs?
10:52 brrt we have bugs, that's for sure
10:52 jnthn Very well; I'll accepted bug reports - preferably nicely golfed - this evening. :)
10:53 FROGGS_ <TimToady> however, MVM_SPESH_INLINE_DISABLE=1 causes my gist to succeed rather than fail on the flip
10:53 FROGGS_ this one: https://gist.github.com/anonymous/0873fd7dd630a9deb6f2
10:53 jnthn ok
10:53 FROGGS_ jnthn: as MoarVM issues?
10:53 brrt some of these bugs are probably my own, though :-)
10:54 jnthn Well, can't hurt to put them there, but let me know on here which ones are most blocking stuff.
10:55 * brrt can't seem to to get asan to work on his machine :-(
10:56 nwc10 if you have enough spare CPU and disk, build gcc 4.9 from source
10:58 brrt or maybe i can, and there's just nothing it can do
10:58 brrt yes, i suppose i do have these :-)
11:08 brrt i'm a lousy programmer, that's for sure
11:11 * carlin wishes he was as half as good a programmer as brrt++
11:12 brrt i think you'll manage that :-)
11:14 carlin looking at what you've done on moar-jit, I don't think so :)
11:14 carlin if that's what you consider lousy... I should fine a new hobby
11:14 carlin *find
11:15 brrt i'm flattered :-) but apparantly, the thing is bug-infested as well, so i'm not so easily pleased with myself
11:16 brrt and certainly don't find a new hobby
11:16 brrt we need all perl6 people we can get :-)
11:20 FROGGS_ jnthn: you got three new issues now
11:21 FROGGS_ https://github.com/MoarVM/MoarVM/issues/117 is the most important I think
11:24 brrt i somehow doubt that the issue that asan finds is as serious as i think it is
11:28 brrt ehm, as serious as ASAN thinks it is
11:31 nwc10 carlin: we'll help you get better, if you want to join in here
11:40 jnthn FROGGS_: For #117, don't suppose you can include the error?
11:42 FROGGS_ jnthn: I can, sec
11:43 jnthn thx
11:43 brrt clang tends to complain about a lot of things gcc doesn't care about
11:44 FROGGS_ jnthn: I commented
11:44 FROGGS_ gcc really is DWIM, and clang is the opposite :o)
11:45 jnthn WAT? :)
11:45 FROGGS_ that's why you usually have portability issues when you develop on gcc only
11:45 brrt DWIM FTW
11:45 FROGGS_ hehe, yeah
11:48 jnthn m: say 'FTW'.flip
11:48 camelia rakudo-moar 2bc8f6: OUTPUT«WTF␤»
11:49 brrt such true
11:49 nwc10 if you really want bondage and discipline, try xlc on AIX
11:51 FROGGS_ ohh, bondage does not sound bad at all
11:51 FROGGS_ or perhaps it sounds bad? like really bad?
11:52 nwc10 http://www.imdb.com/title/tt0093779/quotes?item=qt0482737
11:52 nwc10 paraphrased to "AIX is pain, Highness. Anyone who says differently is an IBM employee"
11:52 nwc10 although, to be fair, AIX make is sane. HP UX is, um, special
12:05 brrt clang is annoyingly slow in comparison to gcc
12:05 nwc10 at what? compiling programs? or bootstrapping its own install?
12:06 brrt compiling programs
12:08 brrt ...... fts
12:08 brrt i'll do it with varargs, then
12:21 jnap joined #moarvm
12:27 jnap joined #moarvm
12:27 klaas-janstol joined #moarvm
12:50 brrt wel, vargs definitilty didn't make it go away, for some reason
13:04 jnthn bbi1h
13:20 brrt ah, i see the problem with the vargs solution now
13:22 brrt ... darn
13:41 * 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...
13:42 FROGGS[mobile] jnthn: would you like to join such a session at some point?
13:57 btyler joined #moarvm
14:04 lizmat joined #moarvm
14:05 brrt http://cdn.meme.li/instances/500x/52847844.jpg
14:10 FROGGS[mobile] hehe
14:11 * brrt is running tests right now and seeing if it helps at all
14:12 brrt btw, looking at create in src/core/interp.c, i think it's possible we've done boxing wrong after all
14:12 brrt but i'd like to have jnthn++'s sage advice on that still
14:14 woolfy joined #moarvm
14:16 dalek MoarVM/moar-jit: e0e0d1d | (Bart Wiegmans)++ | src/jit/ (4 files):
14:16 dalek MoarVM/moar-jit: Add write barrier for sp_p6obind_s
14:16 dalek MoarVM/moar-jit:
14:16 dalek MoarVM/moar-jit: This fixes a heap corruption error in MoarVM that puzzled me
14:16 dalek MoarVM/moar-jit: for the better part of a weekend. Obviously, strings need
14:16 dalek MoarVM/moar-jit: write barriers, too.
14:16 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e0e0d1dd7e
14:21 FROGGS[mobile] I really should ask what write barriers are for
14:22 nwc10 "avoiding headdesk" - I thought that it was obvious :-)
14:23 nwc10 In this context, I can't actually answer helpfully
14:23 brrt which,strings requiring them or what they are for
14:24 brrt 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:28 brrt 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:34 * jnthn lols at the brrtmeme
14:35 jnthn Also, brrt++ for fixing stuff
14:35 timotimo brrt: is this it?
14:36 brrt this is the bug that prevented me from building nqp
14:36 brrt now nqp and rakudo run again
14:36 brrt (and their testsuites, too)
14:36 brrt i've had limited luck adding asan as a Configure.pl option
14:39 brrt also, \o jnthn
14:39 brrt hope you had a great weekend, you were missed by me at least :-)
14:39 lizmat jnthn brrt  nwc10 o/
14:39 lizmat this just on #perl6
14:39 timotimo oh: my \jnthn;#)
14:39 lizmat multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort)
14:40 lizmat segfaults, but only if the subs are called in this order
14:40 lizmat and they're *both* called
14:40 lizmat and it doesn't seem to be spesh related
14:41 lizmat thought this would be a nice, short example
14:41 brrt weird, though
14:41 timotimo word.
14:42 lizmat breakfast&
14:47 jnthn Multi-cache issue, maybe?
14:47 jnthn 2 invocations woudln't be enough for spesh to have kicked in.
14:51 jnap joined #moarvm
15:01 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:02 FROGGS_ brrt: about OP(create)... that means that stuff in registers is MVMROOTed by default, at least in interp.c...
15:02 FROGGS_ and it means that initialize might allocate, which would explain the MVMROOT(tc, box, ... be have seen before
15:02 FROGGS_ (in box_s)
15:03 brrt uhuh
15:03 brrt but... if we assign the box to the register before initializing, we might not need that?
15:03 FROGGS_ if that was the return value, yes
15:04 brrt ok, i'll note it
15:05 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:06 FROGGS_ though, we'd need to pass GET_REG(cur_op, 0).o around, which will get slightly unreadable for set_int for example
15:21 dalek MoarVM/moar-jit: 149c07e | (Bart Wiegmans)++ | Configure.pl:
15:21 dalek MoarVM/moar-jit: Added Configure support for ASAN
15:21 dalek MoarVM/moar-jit:
15:21 dalek MoarVM/moar-jit: ASAN (http://code.google.com/p/address-sanitizer/) is a very
15:21 dalek MoarVM/moar-jit: useful tool for finding all sorts of memory errors in C programs.
15:21 dalek MoarVM/moar-jit: If you have it installed (with recent clang or gcc) then you can
15:21 dalek MoarVM/moar-jit: now get it using the --asan flag.
15:21 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/149c07e20f
15:22 brrt nb, this works better with GCC than clang in my experience, although it /should/ work with clang
15:22 FROGGS_ brrt++ # build-sanitizer
15:40 brrt it's multi cache issue
15:46 timotimo is that the problem with mordre?
15:47 timotimo that actually sounds kinda "right"
15:49 klaas-janstol joined #moarvm
15:55 brrt well, ehm, lets just say that the object that should come from that is not null, not vmnull, and not a pointer
15:56 brrt and right now i'm wondering why rakudo say doesn't compile to nqp::say
15:57 jnthn Needs to be aware of $*OUT. Needs to call .gist on arguments unless they are already strings. Needs to handle multiple arguments.
15:58 jnthn say in NQP is actually a wrapper fwiw
15:59 brrt bbafter lunch
15:59 brrt dinner
15:59 jnthn nom well o/
16:00 brrt tnx o/
16:17 [Coke] dd
16:18 [Coke] er, ww
16:29 woolfy left #moarvm
17:15 brrt joined #moarvm
17:29 lizmat joined #moarvm
17:42 lizmat joined #moarvm
17:42 vendethiel joined #moarvm
17:50 brrt i'm having no luck
17:50 FROGGS_ :(
17:51 brrt perl6 has an impossible amount of multi dispatches just before it runs anything
17:51 brrt well, i'm having some luck, i fixed bugs that perplexed me for a week - and they were simple, too
17:51 brrt but not with the multi cache thing
17:55 brrt oh
17:55 brrt num_args is 0
17:55 brrt (huh, that shouldn't happen?)
17:58 brrt what are acceptable values for arg_flags?
17:59 brrt ok, i'm at the breaking function that returns such a weird pointer
18:00 FROGGS_ look at MoarVM/src/core/callsite.h:5:    MVM_CALLSITE_ARG_OBJ = 1
18:03 brrt aha
18:07 brrt it looks suspiciously like num_args should not be num_pos
18:21 brrt ok, so i know why lizmat++'s bug happens
18:22 brrt the multi in question has no positionals and only a single named argument
18:22 brrt the fact that it has a named argument is sufficient reason for the multi cache to keep looking
18:22 jnthn I can see where this might be going... :)
18:22 brrt but, it uses the number of positionals as a total argument count and an index to the arity cache
18:23 brrt 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
18:23 brrt because, at some point in the past, somebody said 'zero arity, we already have a slot for that'
18:23 lizmat joined #moarvm
18:24 TimToady I sense a disturbance in the force...
18:25 brrt anyway, you're reading - quite possibly - somewhere in the body and interpreting that as a cache object
18:26 brrt 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 brrt in fact it seems that this is about the question 'how do named args contribute to arity'
18:26 jnthn Well, they don't; the cache already has some stuff relating to nameds handling.
18:27 brrt very well
18:27 brrt then the correct response on any zero-positional callsite should be NULL, i think
18:27 jnthn Oh, no; it's got a special slot for a zero-arity solution
18:28 jnthn foo() should be cacheable
18:28 jnthn It's just that something, somehow, goes wrong when there's a foo(:name)
18:28 brrt and what about foo(:fort)
18:29 jnap joined #moarvm
18:31 brrt well, in this case, it tries to look at arity_caches[-1]
18:31 jnthn Yeah, it should never make it that far
18:32 jnthn if (num_args == 0 && !has_nameds)
18:32 jnthn return cache->zero_arity;
18:32 jnthn I think that's the nice at fault
18:33 jnthn I think it wants to be more like
18:33 jnthn if (num_args == 0)
18:33 jnthn return has_nameds ? NULL : cache->zero_arity;
18:33 brrt seems legit
18:38 brrt ok, that works :-)
18:39 brrt https://gist.github.com/bdw/69c277a8aed133cfe6ba please review, and if ok, i'll commit and push it
18:40 jnthn seems legit, though the comment ("bail if") isn't quite true; it's more like "only add if there are no nameds"
18:41 brrt will change
18:43 FROGGS_ ohh I love bug fixes these days
18:44 TimToady .oO(Perl 6 is so wonderful you can even do pair programming by yourself...)
18:44 FROGGS_ *g*
18:50 dalek MoarVM: 2748afd | (Bart Wiegmans)++ | src/6model/reprs/MVMMultiCache.c:
18:50 dalek MoarVM: Fix issue with zero-arity named multis
18:50 dalek MoarVM:
18:50 dalek MoarVM: Named arguments do not count for the arity in the
18:50 dalek MoarVM: MVMMultiCache, however they do not fit in the
18:50 dalek MoarVM: 'zero arity' slot either. Consequently, when supplied
18:50 dalek MoarVM: with a callsite without positionals but with named arguments,
18:50 dalek MoarVM: the cache algorithm searched for matches in a negative offset
18:50 dalek MoarVM: of the arity entries array. This fixes that by refusing to
18:50 dalek MoarVM: deal with such callsites.
18:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2748afdf49
18:51 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
18:53 brrt well, ven++ then too :-)
18:55 * brrt will be feeding gooslings for a bit
18:56 brrt jnthn: are extops ever invokish?
18:58 timotimo they could conceivably invoke i think
18:58 timotimo as in: i think i could build one that is and therefor it should be accounted for
19:30 jnthn brrt: Yes, they can be, but I think they may be rare enough we can get away with not JITting them
19:31 timotimo do we store which extops are invokish and which aren't?
19:32 timotimo because not jitting any frames that have extops in them will bite us when we're in perl6 code, i believe
19:35 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 #moarvm
20:05 Ven joined #moarvm
20:17 brrt joined #moarvm
20:20 jnthn Oh dear.
20:20 jnthn src\strings\unicode.c(42938) : error C2065: 'entry' : undeclared identifier
20:20 jnthn src\strings\unicode.c(42938) : fatal error C1003: error count exceeds 100; stopping compilation
20:21 brrt hmm i see
20:22 brrt clang also complains heavily about src\strings\unicode.c
20:23 jnthn FROGGS_: About 339d547c...
20:23 jnthn 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
20:23 jnthn The top of the file is all like
20:24 jnthn /*   DO NOT MODIFY THIS FILE!  YOU WILL LOSE YOUR CHANGES!
20:24 jnthn This file is generated by ucd2c.pl from the Unicode database.
20:24 jnthn :)
20:24 Ven jnthn: well, he did commit the changes to ucd2c.pl, didn't he ?
20:24 brrt jnthn - do you happen to know if moar-jit is still broken on windows?
20:24 jnthn ohh, uh
20:25 jnthn Yeah, sorry, my git log  command still had the filename in there..
20:25 jnthn brrt: Not yet; can test later today
20:25 brrt please do
20:25 brrt :-)
20:25 brrt or tomorrow
20:26 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
20:27 jnthn FROGGS_: Think I got it fixed now.
20:47 brrt hmm.... it seems ext ops are a bit more involved than i had considered
20:49 FROGGS_ brrt: welome to Perl 6, that is the usual can of worms one trips into :o)
20:52 brrt so true
20:52 brrt or rather i should say
20:54 brrt hmm
20:55 klaas-janstol joined #moarvm
20:56 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 brrt but, i think i've a solution
20:57 dalek MoarVM: 3c2d4aa | jnthn++ | / (2 files):
20:57 dalek MoarVM: Fix MSVC build.
20:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3c2d4aa75c
20:57 brrt ok, i propose the following solution for invokish
20:58 brrt ehm, not invokish, i mean extop
20:59 brrt basically, during spesh codegen, annotate the extop nodes with the offsets into the spesh bytecode
20:59 klaas-janstol joined #moarvm
21:00 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 brrt 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
21:01 brrt (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:02 brrt 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:03 brrt if it was jumpish, then we should fall out to the interpreter, if not, we continue in the jit code
21:03 brrt makes sense?
21:04 brrt (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:07 brrt i'm off for tonight
21:07 brrt see you tomorrow!
21:07 brrt o/
21:07 brrt left #moarvm
21:19 jnthn brrt: Bad news, JIT is still explosive on Windows :(
21:29 lizmat joined #moarvm
21:36 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.
21:37 FROGGS_ k
21:37 FROGGS_ just asking because of merging jit into master
21:43 FROGGS_ m: multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort)
21:43 camelia rakudo-moar 72d574: OUTPUT«(signal )graou~␤»
21:44 FROGGS_ okay, need to wait another 30mins
21:45 lizmat 6 'multi mordre(:$fort!) { "GRAOU!!!!!" }; multi mordre { "graou~" }; say mordre; say mordre(:fort)'
21:45 lizmat graou~
21:45 lizmat GRAOU!!!!!
21:46 lizmat works fine for me  :-)
21:48 lizmat t/spec/S02-types/bag.t , test 118 started flapping for me
21:49 FROGGS_ hmm, not for me
21:54 jnthn On #116, latest is that it fails during a deopt of an OSR'd reify
22:20 FROGGS_ brrt also pasted this, maybe it is related: https://gist.github.com/bdw/e5b606499aa6435f7e72
22:22 FROGGS_ gnight (it is QAST midnight already)
22:24 jnthn That's more an inefficiency (failed to toss instruction) than a bug.
22:24 jnthn afaict, anyways
22:52 hatseflats joined #moarvm
23:05 carlin joined #moarvm
23:22 dalek MoarVM: 986910e | jnthn++ | src/spesh/dump.c:
23:22 dalek MoarVM: Fix spesh dump of num literals.
23:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/986910e5d4
23:22 dalek MoarVM: dab88dc | jnthn++ | src/spesh/dump.c:
23:22 dalek MoarVM: Spesh dumping of lexicals.
23:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dab88dc6ef
23:22 dalek MoarVM: 93597b9 | jnthn++ | src/spesh/osr.c:
23:22 dalek MoarVM: Cope better with a frame being re-OSR'd.
23:22 dalek MoarVM:
23:22 dalek MoarVM: If this happened, the frame may have been resized already. The upshot
23:22 dalek MoarVM: of this is that we didn't do the "allocate zeroed and copy" sequence
23:22 dalek MoarVM: that ensures the environment is empty for the inlinees. Thus, old and
23:22 dalek MoarVM: bogus pointers could end up being grabbed from the previous OSRing.
23:22 dalek MoarVM: Fixing this clones #116.
23:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/93597b9221
23:28 klaas-janstol joined #moarvm
23:28 lizmat joined #moarvm
23:38 dalek MoarVM: b6a4250 | jnthn++ | src/spesh/osr.c:
23:38 dalek MoarVM: Don't try OSR-ing if frame already hit limit.
23:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b6a42501a7
23:40 jnthn Well, that's one of the bugs down at least...
23:42 lizmat so did jit get merged (can't backlog at the moment)
23:42 lizmat ?
23:44 jnthn no
23:44 jnthn I fixed a bug though. :)
23:44 lizmat ok, I wondered because I didn't see a branch in the above commit
23:44 jnthn Sure, the bug I just fixed wasn't JIT-related.
23:45 lizmat ah, ok  :-)
23:55 jnthn Time for some rest...'night

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