timotimo we need something clever so that we can spesh native routines 01:35
the postcircumfix:<( )> method mixed in by the Native role has |args, which spesh does not like (interning of callsites, that is) 01:36
01:37 colomon joined
timotimo but all it does is grab the $!list from the capture and pass it on to nqp::nativecall 01:38
is there something very difficult keeping us from supporting signatures that have only one |foo argument in spesh? 01:41
oh, i've derped 02:05
the flattening that would prevent postcircumfix:<( )> to be spesh'd (or rather: interned) has to be on the callsite, not the signature 02:06
so the signature can be whatever it wants to be, important is only how we call it
and the ways we call that are almost all without flattening, usually
so how come it doesn't show up ...
um ... maybe because we're getlexstatic'ing all the SDL_* functions? 02:10
even in post-spesh code
... did i misread? 02:15
i notice my brain isn't totally up to speed tonight 02:19
02:24 Peter_R joined
timotimo ugh, the post-spesh result of infix:<+> for two Complex numbers is .. dumb 02:30
gist.github.com/timo/b7cc8284db472e35c255 02:31
02:49 ilbot3 joined 03:06 colomon joined
timotimo i'll look into this tomorrow, now is way past my bedtime 03:28
07:54 FROGGS joined 08:14 rurban joined 08:19 kjs_ joined 08:49 zakharyas joined 09:41 FROGGS joined 09:51 kjs_ joined 10:43 kjs_ joined 11:28 kjs_ joined 12:15 Ven joined 12:58 ggoebel111111114 joined, Ven joined
timotimo the lines to fix up the usages were commented out in the p6opaque.c code, i'm going to spectest with these lines reactivated and it seems like i'll have to add a usage-decrease-line for the name of the attribute, too for some instance 13:34
instances
13:46 Ven joined 13:48 Ven joined
timotimo my set removal seems to make a little mistake here 13:55
the set removal i made may reduce the number of superfluous set instructions, but since it doesn't handle fact transfer correctly yet (and i'm too lazy to fix that), i'd be inclined to throw it out until someone writes something better (maybe even me) 14:06
(another way would be to do set removal as a second pass over each BB or over the whole graph) 14:07
jnthn timotimo: I was pondering it in the same pass we will do ref elimination and box/unbox sequence elimination. 14:08
Which will be post-inline
And set elim will help us more post-inline too. 14:09
gotta go for a bit
14:10 colomon joined
timotimo gist.github.com/timo/b7cc8284db472e35c255 ā† now has (at the top, surprisingly) the result of not doing set elimination, but adding more usage reduction to p6opaque 14:13
14:20 colomon joined 14:22 dalek joined
dalek arVM: e929224 | timotimo++ | src/6model/reprs/P6opaque.c:
re-enable usage decrements for get/bindattr in P6opaque
 14:28
arVM: 4d546bc | timotimo++ | src/spesh/optimize.c:
currently, set removal hurts more than it helps.

ideally, there'd be a second pass over the spesh graph that would do set removal, unbox tracking and other post-inline optimizations.
arVM: e5cc1b3 | timotimo++ | src/6model/reprs/P6opaque.c:
another opportunity to reduce usage counts
 14:42
timotimo (note the wval and const_s that are left over, probably because the deopt one point in BB 7 requires the registers to have the same values in them regardless of spesh'd version or not 14:51
) 14:52
15:20 Ven joined 15:50 Ven joined
dalek arVM: 323400c | timotimo++ | docs/ChangeLog:
Draft a changelog for 2015.02
 15:59
timotimo the biggest chunk of work only ended up as a single changelog entry; we may want to elaborate on that a lot more
jnthn timotimo: I normally do git log --oneline --reverse 2015.01.. 16:05
And hack it down from that.
timotimo: I want to work on the native ref elimination over inlines in the next week or two, so maybe I'll look at a new set elimination pass at that point. 16:07
timotimo cool :) 16:08
jnthn And box/unbox too
My gut tells me the 3 want a similar algorithmic approach.
timotimo if there's simple but annoying footwork i could prepare for you, feel free to outline it 16:09
17:18 kjs_ joined 17:34 camelia joined 17:36 kjs_ joined 17:47 rurban joined 18:03 tgt joined 18:06 Ven joined 18:20 FROGGS joined 18:55 kjs_ joined 19:37 zakharyas joined
dalek arVM: 5121acd | jnthn++ | docs/ChangeLog:
Flesh out ChangeLog some more.

  timotimo++ for getting this started.		 20:05
jnthn timotimo: There really ain't much to do :) 20:06
timotimo: It's just bump the VERSION file, do make release, and check the resulting tarball
(Instructions in docs/release_guide.md)
Also, yeah, apparently * is the changelog char for 2015 :P 20:11
20:20 camelia joined
timotimo i didn't even notice the memory leak with bigints 20:24
but i don't use bigints very often
(especially since the smallbigint stuff)
jnthn iirc it was only a deserialization time one
And only for big ones
So it wasn't likely to hurt much.
timotimo oh, OK 20:26
jnthn Still, good to nail 'em all 20:27
timotimo yes
very much so
jnthn Will be back tomorrow morning to work on relesae stuff if nobody beats me to following the release guid :)
*guide
o/
timotimo i can do that
good night!
20:33 dalek joined 21:02 dalek joined 21:09 camelia joined
FROGGS reprs.obj : error LNK2001: unresolved external symbol MVMCPPStruct_initialize 21:10
moar.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\x86_amd64\link.EXE"' : return code '0x460'
sad, I wanted to test it on windows "quickly"
21:14 rurban joined
dalek arVM: f67647f | timotimo++ | VERSION:
we have a release! 2015.02
 21:24
timotimo i hope i didn't wrong 21:25
moritz YOU BORKDED IT! 21:26
erm, just kidding :-)
timotimo++ 21:27
timotimo i'm not sure i have an ssh access to moarvm.com 21:29
lizmat neither 21:30
21:33 colomon joined 22:05 FROGGS_ joined 22:38 colomon joined 22:57 kjs_ joined
timotimo jnthn: here's the tarball in case you've missed it in #perl6 or just want to spend less time hunting for it: t.h8.lv/MoarVM-2015.02.tar.gz 23:10
23:31 kjs_ 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!