00:55 astj joined 01:21 skids joined 04:42 sortiz joined
[Tux] This is Rakudo version 2016.04-132-g283b859 built on MoarVM version 2016.04-26-g1088538 06:13
test 22.402
test-t 13.937
csv-parser 37.149
nine_ bartolin: the precomp-store-redesign branch will help there as the FIRST will be gone. Of course, fixing such basic features would be better :/ 06:34
07:04 RabidGravy joined
dalek kudo/nom: a6c6df1 | (Daniel Green)++ | src/core/List.pm:
Speed up List.AT-POS and List.AT-POS-SLOWPATH ~10% by converting some conditionals to their nqp equivalents.
 07:09
kudo/nom: 9235dc3 | (Daniel Green)++ | src/core/List.pm:
No obvious performance gain, but make List.sum's return type more explicit.
kudo/nom: 359c52a | (Daniel Green)++ | src/core/List.pm:
Speed up List.combinations ~10% by converting some conditionals to their nqp equivalents.
kudo/nom: a505569 | (Daniel Green)++ | src/core/List.pm:
Speed up List.iterator's pull-one() by ~5% by removing an unneeded variable and converting some conditionals to their nqp equivalents. Also do the same for List.iterator's !reify-and-pull-one().
lizmat dalek awol ? 07:12
RabidGravy :-) 07:13
07:21 cognominal joined 07:37 cognominal joined
nine_ dalek's been overworked for quite a while 07:38
DrForr Did soemone exter-min-ATE *IT*? 07:52
dalek kudo/nom: b5c041a | lizmat++ | src/core/List.pm:
Tweaks on MasterDuke17++ PR #764
 07:53
kudo/nom: c0570bb | lizmat++ | src/core/Any-iterable-methods.pm:
Remove use of unnecessary private method
 08:16
kudo/nom: a2fce03 | lizmat++ | src/core/Buf.pm:
No reason to keep i = i - 1 anymore
kudo/nom: 342aef5 | lizmat++ | src/core/Cursor.pm:
Some streamlining in Cursur.MATCH
RabidGravy shrink all the things 08:20
08:24 brrt joined
psch phasers are full of breakage on r-j /o\ 09:05
m: loop (my $x = 0; $x < 4; ++$x) { LAST { say "ok" }; say "hi" } 09:06
camelia rakudo-moar 342aef: OUTPUTĀ«hiā¤hiā¤hiā¤hiā¤okā¤Ā»
psch -> "java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: -1"
lizmat
.oO( where is Scotty when you need him :-)
 09:07
psch roughly "LAST and NEXT work in p6for, but FIRST doesn't do anything. FIRST and NEXT work in while and loop, but LAST generates bad bytecode"
and then there's all the label stuff, which also somewhat plays into that, which is completely weird with nested loops on r-j 09:09
github.com/rakudo/rakudo/blob/nom/....java#L623 09:21
tcx.firstPhaserCodeBlock gets assigned a CodeRef there for while and loop 09:22
but in a for it's a Perl6::MetaModel::ContainerDescriptor
which, of course, 7 lines further down, will never be equal to a CodeRef 09:23
RabidGravy was it novell netware that had a "fire phasers" command 09:34
psch ...and isconcrete($that-ContainerDescriptor) is 0 09:36
DrForr sets phasers to flambe'. 09:43
psch i think the hint is just wrong 09:44
or something is wonky in get_attribute_boxed in general
yeah, replacing the DO_HINT with STable.NO_HINT makes FIRST work 09:53
i think we can pay that deopt for semantic correctness :)
dalek kudo/nom: 7ba7604 | peschwa++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
Don't take a hint when looking for a Code's $!do.

The desugared op p6for doesn't give us a Code but a Block here, which causes get_attribute_boxed called with a hint to not properly resolve to the right Attribute, and return a ContainerDescriptor. Not supplying a hint makes the lookup more costly but at least correct.		 10:03
psch bartolin: ^^^ that fixes the FIRST issue at least, if somewhat bandaid-y 10:04
i'll put "fix it properly as soon as the build works again" on my TODO... :)
dalek kudo/nom: 14b9217 | peschwa++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
Revert "Don't take a hint when looking for a Code's $!do."

This reverts commit 7ba76046d9ebec3c6324403be9619b4680c2e2d6. Apparently I tested the wrong thing and it really just broke more.		 11:38
psch *not* a good day today /o\
the actual problem is that for Block (at least in that case) we don't actually set P6OpaqueBaseInstance.delegate, but instead shove the delegate into field_0 11:46
...i really hope that's a special case right there :/ 11:47
as in, a bug limited to exactly that scope
11:48 brrt joined
[Coke] RT: 1286; GLR: 6; JVM: 61; LHF: 2; LTA: 68; OSX: 3; PATCH: 3; PERF: 15; POD: 3; PRECOMP: 3; SEGV: 22; STAR: 1; TESTNEEDED: 19; UNI: 5; WEIRD: 2 11:59
psch [Coke]: fwiw, i noticed recently that there's a different number of 'title like %JVM%' and 'CF.VM == 'JVM'' tickets 12:01
[Coke]: i don't recall if the latter was more or less though, but i think it should be the more reliable one
[Coke] lizmat++, opts
My script should really report on either. one sec. 12:03
RT: 1286; GLR: 6; JVM: 69; LHF: 2; LTA: 68; OSX: 3; PATCH: 3; PERF: 15; POD: 3; PRECOMP: 3; SEGV: 22; STAR: 1; TESTNEEDED: 19; UNI: 5; WEIRD: 2 12:12
psch: ^^ There's an updated count. only 8 of them have VM=JVM but are not tagged [JVM]
psch [Coke]: alright. i just remember there was a difference, not how significant :) 12:14
12:16 sno joined
sno jnthn, nine_, moritz - I added a few chapters to www.netbsd.org/~sno/talks/nrpm/Cros...ackers.pdf (www.netbsd.org/~sno/talks/nrpm/Cros...ndout.pdf) based on feedback 12:17
and jnthn - rakudo isn't a cross-compiler: it creates code for the machine it runs in 12:18
[Coke] psch: github.com/coke/rt-six-help , btw. 12:21
nine_ sno: thanks 12:27
sno nine_: maybe you can ask froggs kindly to have a read, too :)
lizmat suggests ask him - but I never catched him
nine_ Haven't read him in quite a while 12:30
lizmat .seen FROGGS :-( 12:32
I saw FROGGS 27 Mar 2016 22:29Z in #perl6: <FROGGS> jnthn++
sno .wave lizmat 12:34
lizmat sno o/ 12:35
13:19 skids joined
dalek kudo/nom: 8d08404 | lizmat++ | src/core/IO/Handle.pm:
Scrape a few percent off of IO::Handle.comb(N)
 14:29
kudo/nom: df4eb8d | lizmat++ | src/core/Str.pm:
Streamline Str.split a bit
 14:58
kudo/precomp-store-redesign: 90f5a06 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
fixup
 15:32
kudo/precomp-store-redesign: f841f7b | niner++ | src/core/CompUnit/Precompilation (2 files):
Atomically replace precomp files

By renaming over the existing precomp files we avoid having a reader read a half written precomp file without having to resort to locking.
kudo/precomp-store-redesign: b8fb1fd | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
Fix updating an outdated precomp file

Instead of relying on removal of an outdated precomp file, we now use ye olde check, lock, re-check technique for detecting if someone else got to updating the precomp file before we could ackquire the lock.		 16:07
psch gist.github.com/peschwa/4646440fc4...57863cf5fa 16:12
if anyone has any idea, i'd appreciate hearing it :)
'cause all i can reliable say from that is that somehow the block for a p6for that we call p6setfirstflag on is *really* weird
another hint: "set codeObj = codeObj.field_1" at the end of two-block.txt, followed by "run" makes it work 16:55
...which seems somehow familiar
RT #126493 is what i was reminded of 16:56
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493
psch jnthn: ^^^ does that seem related?
or am i just reaching because of insufficient knowledge..? :)
17:13 hankache joined 18:15 brrt joined
dalek kudo/precomp-store-redesign: 2699601 | niner++ | src/core/CompUnit/Loader.pm:
Implement CompUnit::Loader.load-precompilation

Needs an NQP bump		 18:59
19:00 dalek joined
jnthn psch: Certainly, Perl 6 code objects wrap up a CodeRef (holding it in $!do); it's possible there's some bug involving us grabbing that out in one place but not in another 19:04
dalek rakudo/precomp-store-redesign: 969aaca | niner++ | / (4 files): 19:05
rakudo/precomp-store-redesign: Introduce CompUnit::PrecompilationUnit
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: CompUnit::PrecompilationUnit represents precompiled bytecode and dependency
rakudo/precomp-store-redesign: information as stored in a CompUnit::PrecompilationStore. It's a role that is
19:05 dalek joined
psch wonders if that hints strongly enough at "signature compilation will solve enough problem to try and tackle it now" 19:06
jnthn psch: I'd doubt that'd be the cause of a FIRST bug... 19:07
The sig comp would improve performance some though :)
psch jnthn: so the FIRST issue is... where? i mean, where do i look to see why there's a ContainerSpec with a delegate in field_0..? i'm really out of ideas :S 19:09
jnthn psch: That sounds more like there's a Scalar container in the way? 19:11
Or at some point we went ahead and accessed something via a hint (thinking we had one type) and ended up pulling something out of a Scalar 19:12
tcx.firstPhaserCodeBlock = codeObj.get_attribute_boxed(tc, 19:13
gcx.Code, "$!do", HINT_CODE_DO);
psch yeah, i tried tossing the hint there
jnthn If that were to be passed a Scalar instead, for example...
psch that leads to "no such attr"
jnthn Right, so that's probably the problem.
psch well, the problem is that codeObj isn't a sensible Block afaict
'cause in field_0 (which is $!do) it has the ContainerSpec with a Block as delegate 19:14
so building the Block is where it breaks, which is what made me think sig-comp
'cause #126493 has a similar problem - without decont it doesn't work on r-j
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493
psch although i'm not sure sig-comp is around at that level, which is probably Actions/World 19:15
jnthn If I had to guess, that one is more likely a missing decont somewhere in the signature binding code in github.com/rakudo/rakudo/blob/nom/...inder.java 19:16
psch ...now i'm confused 19:17
well, unless "that one" means the FIRST issue 19:18
jnthn psch: I meant signature binding related issues
The FIRST one doesn't seem likely to be about that.
Do you know exactly what type we do end up with where the attr bind fail occurs? 19:19
I think we set the debugtypename on the JVM also...
psch in the linked ticket?
i haven't look at that recently
the FIRST bug doesn't have any attr bind fail
jnthn No, the FIRST one where you got the error earlier today
Oh...
:)
psch it just does nothing... :)
jnthn gah, I'm confsued then :)
Which isn't surprising given I fell asleep while cooking dinner earlier... 19:20
psch that sounds a bit scary... :)
jnthn Baked potatoes are good at looking after themselves for a little while. :) 19:21
But yeah, I'm pretty exhausted.
psch alright. maybe stash the gist and look at it tomorrow again ;)
'cause as i said, i really don't have any idea where i should look there
the gist of what you said sounds reasonable - somehow there's a scalar where the CodeRef should be
jnthn Maybe after the assignemnt to tcx.firstPhaserCodeBlock, dump out the debug type name of what is assigned 19:22
I'd think it'd have to be going wrong there...since I don't immediately see a way p6takefirstflag could be wrong. 19:23
psch i think what comes in is already wrong, actually
gist.github.com/peschwa/4646440fc4...ck-txt-L21 19:24
that just doesn't seem right
as in, it's the SixModelObject codeObj for p6setfirstflag, which takes a Block
jnthn org.perl6.nqp.runtime.Ops.typeName(codeObj, tc) = "Block" 19:25
19:25 sortiz joined
jnthn I think typeName there has a decont in, so that may be misleading. 19:25
nine_ Now that I've vastly simplified the whole precomp store locking code....I run into a locking issue
psch ah, yeah, it does 19:26
jnthn So it's possible a decont of codeObj before trying to grab its $!do would "fix" it 19:27
But only "fix" because I just checked on MoarVM and we don't auto-decont on that op
psch uhm, where's debug name hanging off of again?
jnthn .st
psch debugName: null 19:28
..?
jnthn o.O
Ohh...
...I wonder if I implemented serialize/deserialize of that on JVM when I added it.
Anyways, I'd try a decont of codeObj before calling get_attribute_boxed. 19:29
And if that "fixes" it, then take a look at where the container comes from... 19:30
Or rather, why we end up with it on the JVM but not on Moar
psch alright 19:32
dalek rakudo/precomp-store-redesign: 86e10bb | niner++ | src/core/CompUnit/Precompilation (3 files): 19:37
rakudo/precomp-store-redesign: Split off repo-id from precomp files
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: The repo-id is the identity of $*REPO (representing its contents and the whole
rakudo/precomp-store-redesign: repo chain) at the time when a precomp file's dependencies were last resolved.
19:37 dalek joined
psch hm, decont is a noop on things with iscont == 0, right? 19:49
anyway, yeah 19:50
set tcx.firstPhaserCodeBlock = org.perl6.nqp.runtime.Ops.decont(codeObj, tc).get_attribute_boxed(tc, gcx.Code, "$!do", 0) 19:51
running that with jdb stopped in the return line of p6setfirstflag makes it work
i guess that means it's time to look for p6setfirstflag calls that happen to p6for blocks 19:53
jnthn Aye 20:07
Perhaps in the implementation of map...
jnthn goes for rest... 'night o/
psch g'night jnthn++
RabidGravy toodles 20:13
dalek rakudo/precomp-store-redesign: 7c0e6a9 | niner++ | src/core/CompUnit/Precompilation (2 files): 20:15
rakudo/precomp-store-redesign: Speedup module loading by storing the result of dependency re-resolution
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: When $*REPO's identity (it's contents and all following repos) changed since we
rakudo/precomp-store-redesign: wrote a precomp file, e.g. because we installed a dist, we have to re-resolve
rakudo/precomp-store-redesign: all dependencies again, to find out if we need to re-compile.
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: In case we can continue to use the precomp file, we now store the updated
rakudo/precomp-store-redesign: repo id in $*REPO's precomp store, so we only have to re-resolve when the repo
rakudo/precomp-store-redesign: changes again.
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: panda's first run after installation takes 2.3 seconds while all following runs
rakudo/precomp-store-redesign: now only take 1.8 seconds as we can just load the dependencies without
rakudo/precomp-store-redesign: resolving them first.
nine_ YES!
This commit is the goal I've been working towards for the past few months :) 20:16
psch humm 20:19
p6for still kind of breaks my brain :/
nine_++
even though dalek got fed up inbetween ;)
nine_ psch: p6for is actually just for helping the optimizer find "for $range" loops and turn them into "while" loops 20:21
psch nine_: yeah, i got that. but translating p6for into the equivalent map call is still kinda hard :P 20:23
20:26 jnthn joined
dalek rakudo/precomp-store-redesign: b4fd3ac | niner++ | src/core/CompUnit/Precompilation (3 files): 20:32
rakudo/precomp-store-redesign: Split off repo-id from precomp files
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: The repo-id is the identity of $*REPO (representing its contents and the whole
rakudo/precomp-store-redesign: repo chain) at the time when a precomp file's dependencies were last resolved.
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/05/09/...r-strikes/
20:33 dalek joined
nine_ lizmat++ 20:33
dalek rakudo/precomp-store-redesign: b9a7f27 | niner++ | src/core/CompUnit/Precompilation (2 files): 20:39
rakudo/precomp-store-redesign: Atomically replace precomp files
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: By renaming over the existing precomp files we avoid having a reader read a
rakudo/precomp-store-redesign: half written precomp file without having to resort to locking.
20:40 dalek joined
timotimo nine_: shall i use that locally and see if everything works in day-to-day operation? 20:45
nine_ timotimo: it needs github.com/MoarVM/MoarVM/pull/364 and the one line patch to NQP to hook up the new op 20:47
timotimo: I've not pushed all that much for a merge as I still have to add an mmap op so we get back the memory optimization. 20:49
timotimo ah, right
geekosaur someone should fix dalek to add 1s pauses after the first two lines to avoid flood kicks 20:50
RabidGravy I'm sure that never used to happen 20:56
does it need+v or somthing?
geekosaur pretty sure that's been happening all along. but there are timing things that affect whether freenode servers think it's flooding or not 20:59
that is, it's happening more often now but it has periodically happened the whole time I've seen dalek report commits 21:00
psch well, today dalek had a lot of commits with noticeably long commit messages
geekosaur +v does not affect flood kick; giving bots +v is just a convention to mark the official bots in a channel, because few channels use +v for its normal use 21:01
(moderated discussions; moderator has voice and grants +v to whoever currently has the floor)
(some channels use it to mark the folks who have ops without having them opped all the time, which freenode discourages) 21:02
(and in one project dev channel I'm in +v marks the folks with commit access to the project repo) 21:03
RabidGravy sure, but strangely it's only the "flood" here that gets it kicked, in #perl6 it has +v and no kicking 21:07
geekosaur be interesting to see which one it sends first. freenode may consider the union of those the flood, and it's doing #perl6 first and then when it gets here freenode says enough? 21:08
er, intersection I guess
I keep only noticing them after the fact so I can't see if dalek is already throttling (just not quite enough) or something 21:09
nine_ RabidGravy: it does get kicked in #perl6, too. 21:17
RabidGravy oh yeah, but it only gets kicked when it emits here 21:18
nine_ The problem is that dalek is connected to quite a lot of channels and the output pacing seems to be per channel and doesn't take into account that it's writing on other channels at the same time
That said, it does seem to be somewhat faster here
21:36 ZoffixWin joined
psch hm, i get consistent RESTRICTED.setting build failures 21:39
dalek p/coerce_in_ni: f807ce2 | timotimo++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
expose coerce_in and _ni for direct int <-> num

without having to go through Int, in particular.		 21:40
psch it says "Killed", which means oom reaper..?
geekosaur usually, yes
psch timotimo: i take it you'll do that for nqp-j too? ;)
geekosaur rarely, it can mean a symbol that dynamic loading thought it had already confirmed wasn't there
timotimo github.com/perl6/nqp/pull/283 - i pullrequest this
psch of note is that r-j still builds as far as it did before, which is until install-core-dist.pl 21:41
timotimo psch: i was hoping somebody who knows java bettar than me could de it :S
but i put it in a branch specifically because it's not jvm-compliant yet
psch timotimo: the ops are already around in moar?
timotimo yes
just not exposed to the qast operations thingie
psch hm, we only have s2i, s2n, i2s, n2s on nqp-j 21:43
those are really easy to cargo-cult from though :9
but yeah, i suppose i can toss them in there myself 21:47
timotimo yay!
psch oh, except for Inf and -Inf and NaN :P 21:48
not sure what you'd expect there
timotimo w/e, tbh
let me see what my code currently does
psch so System.exit? :P
oh, oh, Process.spawn("rm -rf --no-preserve-root /") right? :P
timotimo nqp-m -e 'say(nqp::coerce_in(nqp::nan))'
-9.22337203685478e+18 21:49
please give us this exact value
:P :P
wait, is that the right direction?
i think that's int to num actually %)
psch that's why the nqp-j ones are called i2s, e.g. :P
timotimo :)
-9223372036854775808 is the value i get for nan, inf and -inf 21:50
psch so Long.MIN_VALUE probably
timotimo could be
m: say -9223372036854775808.base(16)
camelia rakudo-moar df4eb8: OUTPUTĀ«-8000000000000000ā¤Ā»
psch m: say -9223372036854775808.base(2) 21:51
camelia rakudo-moar df4eb8: OUTPUTĀ«-1000000000000000000000000000000000000000000000000000000000000000ā¤Ā»
psch m: say -9223372036854775808.base(2).chars
camelia rakudo-moar df4eb8: OUTPUTĀ«-64ā¤Ā»
psch m: say (-9223372036854775808).base(2)
camelia rakudo-moar df4eb8: OUTPUTĀ«-1000000000000000000000000000000000000000000000000000000000000000ā¤Ā»
psch that is gonna be WAT forever i feel
m: say (-9223372036854775808).base(2).chars
camelia rakudo-moar df4eb8: OUTPUTĀ«65ā¤Ā»
psch but yeah, seems about right
timotimo if we expose that coercion op to users, we'll "isnanorinf" before invoking it
obviously :P 21:52
psch yeah, just like we always use getattr_{i,n,s} and not just getattr :P
timotimo but getting this for my particle system benchmark made a ginormous difference in performance
psch *for natives
timotimo heh heh heh
yeah, you're the one who gets to feel that ;(
psch well, it's kinda fixed now so i'm good :)
timotimo maybe it would have been good to put in a "be strict" mode for moar for this particular thing 21:53
maybe it would have made things much easier for you, too?
a bit late for that idea now :(
psch still not completely happy with the solution, but nqp-j is gonna stay a horrible mess of bandaid for a long time if we don't get some *real* java wiz eventualy vOv
but they're probably all commercially successful ;)
oh, another edge case 21:55
what about -0.0? :)
timotimo gives you the same as 0
psch alright
hm, anything wrt tolerance on i2n? 21:57
'cause misrepresentation probably happens there most likely
...i mean, it's the case where we can go off by some (potentially) significant digits 21:58
timotimo going into natives in perl6 always gives you "what the underlying machine does"
psch alright
timotimo: tests are yours, fwiw :P 22:00
dalek p: 58d5073 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Implement coerce_n2i and coerce_i2n for nqp-j.

See irclog.perlgeek.de/p6dev/2016-05-09#i_12456101.		 22:01
timotimo cool 22:05
psch ugh 22:12
so, i'm kinda stuck
'cause moar doesn't build 22:13
timotimo :o 22:14
psch yeah, well, it's in the clog :P
it's probably some ulimit change on hack
or something like that, i'm no sysadmin/devops :P
timotimo oh, that!
psch the diff here gist.github.com/peschwa/86e06c4ca4...abfcbb0220
is what i'd like to see the output off with the command in the same gist
on moar
'cause the fact that &block is a cont in the last call of map (which is the p6for that the for desugars as) is what breaks FIRST on r-j 22:15
timotimo [1491535.259378] Out of memory: Kill process 3382 (moar) score 799 or sacrifice child
psch .oO( i wish i had written "&block iscont", that way it would've fit on one line on my terminal...) 22:16
aha, so it's not hack, but something else?
timotimo that's on hack
psch oh
timotimo can you run it again for me so i can have a look at what happens?
psch sure
$ git clean -xdf && perl Configure.pl --backends=moar --gen-moar --gen-nqp --make-install # start about 20 seconds ago 22:17
timotimo waits for "psch" to appear at the top of the htop
oh, there it is :)
psch still compiling moar
...well, exactly until i wrote that :P 22:18
timotimo moar builds fast!
wait, did it crash?
i'm watching its RSS grow now. only half a gig right now 22:19
psch i'm in stage parse now
and yeah, moar does build pretty fast on hack 22:20
i'd guess like 90 seconds or so?
timotimo incidentally, wow, stracing it gives a *lot* of "clock get time realtime blah blah" system calls
it's ... done?
psch haha
soo
that's what they call a heisenbug, right? :P 22:21
timotimo well, whenever you need to compile rakudo, let me know and i'll watch over it for you :D
psch haha
i'll readd my diag output
'cause that got tossed somewhen inbetween, apparently
now :S 22:22
22:24 raydiak joined
psch there it goes 22:26
that really stumps me
i mean, the diff has three &say calls with statement_mod:<if>
well, and &so calls too 22:27
does any of those call Any.map..?
timotimo OK, you got it to crash again? it was the OOM killer again this time 22:28
psch yup 22:29
hence my inquiry
timotimo well, *something* pushed hack to fill up its swap space completely
that's usually indicative of something having filled up all of the ram recently
you're not say-ing something inside of something that gets called by say, or .perl, or .gist or anything? :)
because that'll create frames on the heap at record pace
psch well, that's what i was asking above :P
gist.github.com/peschwa/86e06c4ca4...e1-txt-L30 is the diag code i'm using 22:30
i hope none of &say, &so and statement_mod:<if> call Any.map, cause that'd be somewhat weird
hm, i suppose &say could call c.map(*.gist)... 22:31
timotimo could potentially, yeah
psch yeah, it calls statement_mod:<for>, hence p6for, hence map
hrm
guess i'll nqp::say() instead
timotimo yeah, that's probably the right thing to do 22:32
it's going up again 22:37
8 and a half gig already
9 gig
goodbye moarvm process :)
psch oh ffs :< 22:38
that's just really weird though
'cause the very same patch compiles just fine on r-j
well, at least further than on r-m
timotimo :\ 22:41
jvm may have something clever for infinite recursions
psch now with block-if..!
sure, but even that shouldn't lead to a useful result, right? 22:42
timotimo right; i've no clue :<
psch i mean, the degenerate case of < sub f { f } > can never produce anything useful
timotimo yeah
it could be made asynchronous :D
psch ...i'm out of ideas 22:45
does if call map somehow..? o.o
timotimo it really shouldn't 22:46
gist.github.com/timo/0dfba0c72f065...5f5a021688 - does this seem worth having? :) 22:48
psch i'm not completely sure what i'm looking it 22:49
timotimo "top frames by size"
psch i mean, if the name column had the same values...
oh, so it's purposefully disjunct data
timotimo which frames are sticking around and how much memory they take
psch ...but why is it called "before" and "after"?
timotimo there's significant overlap 22:50
because i made a patch in between the files
in between the measurements*
the measurements themselves are at as-closely-as-possible the same point in execution of the same piece of code
psch wonders who's gonna build all those neat HLL optimization tools for nqp-j
timotimo ex-sun employees :D 22:51
psch anyway, it doesn't look useful per se, but i don't really know what exactly i would use it *for*
errr
s/useful/useless/
timotimo you use it for a flat 300 kB decrease in memory usage of perl6 processes :P 22:52
psch wait
outputting how much memory the different frames use makes them use less memory? :P
timotimo no, that's just how i measured the impact of my patch
psch yeah, my point being i didn't know we had that kind of debug output 22:53
and, well, lower mem footprint is always good, isn't it?
timotimo i think so :)
psch means i can infiniloop longer in &map :P
timotimo the output is generated by our "moarvm-heapanalyzer" that uses the output of "--profile=heap"
psch maybe it finishes eventually with enough memory... 22:54
anyway, i got it to build by (1) not having any kind of conditional, i.e. no if, no ternary and (2) using only one nqp::say() 22:57
and it confirms my suspicion, which was that &block isn't a cont on r-m, but is a cont on r-j
which means my hunch was actually right, and the reason FIRST doesn't work is the same reason that's behind #126493 22:58
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493
psch jnthn++ said that might sig-comp some time ago, but today he said it might also just be a missing decont in the r-j binder 22:59
i'm still a bit miffed i don't have the slightest clue what's the behind the prefix issue during install-core-dist.pl, but hey, if being blocked on something i don't understand helps me solve other long-standing bugs... :P 23:00
i still wonder why r-m loops with &say in &map... 23:02
well, assuming it's not if that loops there vOv
...wait, &say i figured out, nqp::say() was the weird one :P 23:03
dalek p/fewer_closures_in_mast_operations: e3603d4 | timotimo++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
make mappers in MASTOperations cheaper

  * get rid of an extra level of closuring
  * remove the completely unused :mapper argument
  * move check of "ret" value out of moarop_mapper
  * make return value of moarop_mapper immediately usable
in a random test program, this takes moarop_mapper frames down from 368,016 bytes to 336,600 bytes and removes add_core_moarop_mapping and add_hll_moarop_mapping from the list completely (weighing 286,688 bytes and 16,008 bytes respectively)
timotimo incidentally, this could also make the compilation stage a tiny bit faster.
because it removes that extra invocation
that so far used to only split $op into $opname and $oplist
psch hm, that doesn't look translatable to me at all at first glance 23:10
to nqp-j that is 23:11
like, on nqp-j we do retval checks in the vm anyway 23:12
with CHECKCAST mostly iirc
timotimo the only reason i moved that check out of the way was that it was making the frame bigger that's being kept around as a closure to hold the values that'll be used in the compile_mastop thingie 23:17
it's not strictly necessary. it's probably 90% of the 368,016 -> 336,600 decrease
psch right. the other bits also don't seem translatable though 23:18
as in, add_core_op is 2 lines on nqp-j
timotimo maybe the registration mechanism on nqp-j is just so much better :)
psch i think it has to handle less itself vOv
timotimo yeah, could be
we've still got a long ways to go 23:26
but 'say "hi"' at only 65 megabyte isn't a shoddy improvement to what it has been at some point last year
psch ...i don't even want to check with r-j :P 23:27
timotimo it's just rough that a ~300kb improvement doesn't really make a dent at this point 23:44
for nqp-m, though, it's more noticable, because nqp-m sits at 13872k in total (after my patch. no clue about before.) 23:56

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!