Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-09

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

All times shown according to UTC.

Time Nick Message
00:55 astj joined #p6dev
01:21 skids joined #p6dev
04:42 sortiz joined #p6dev
06:13 [Tux] This is Rakudo version 2016.04-132-g283b859 built on MoarVM version 2016.04-26-g1088538
06:13 [Tux] test            22.402
06:13 [Tux] test-t          13.937
06:13 [Tux] csv-parser      37.149
06:34 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 :/
07:04 RabidGravy joined #p6dev
07:09 dalek rakudo/nom: a6c6df1 | (Daniel Green)++ | src/core/List.pm:
07:09 dalek rakudo/nom: Speed up List.AT-POS and List.AT-POS-SLOWPATH ~10% by converting some conditionals to their nqp equivalents.
07:09 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a6c6df1f10
07:09 dalek rakudo/nom: 9235dc3 | (Daniel Green)++ | src/core/List.pm:
07:09 dalek rakudo/nom: No obvious performance gain, but make List.sum's return type more explicit.
07:09 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9235dc332b
07:09 dalek rakudo/nom: 359c52a | (Daniel Green)++ | src/core/List.pm:
07:09 dalek rakudo/nom: Speed up List.combinations ~10% by converting some conditionals to their nqp equivalents.
07:09 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/359c52a415
07:09 dalek rakudo/nom: a505569 | (Daniel Green)++ | src/core/List.pm:
07:09 dalek rakudo/nom: 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().
07:09 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a505569018
07:12 lizmat dalek awol ?
07:13 RabidGravy :-)
07:21 cognominal joined #p6dev
07:37 cognominal joined #p6dev
07:38 nine_ dalek's been overworked for quite a while
07:52 DrForr Did soemone exter-min-ATE *IT*?
07:53 dalek rakudo/nom: b5c041a | lizmat++ | src/core/List.pm:
07:53 dalek rakudo/nom: Tweaks on MasterDuke17++ PR #764
07:53 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b5c041a6ca
08:16 dalek rakudo/nom: c0570bb | lizmat++ | src/core/Any-iterable-methods.pm:
08:16 dalek rakudo/nom: Remove use of unnecessary private method
08:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c0570bb941
08:16 dalek rakudo/nom: a2fce03 | lizmat++ | src/core/Buf.pm:
08:16 dalek rakudo/nom: No reason to keep i = i - 1 anymore
08:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a2fce03212
08:16 dalek rakudo/nom: 342aef5 | lizmat++ | src/core/Cursor.pm:
08:16 dalek rakudo/nom: Some streamlining in Cursur.MATCH
08:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/342aef5a2e
08:20 RabidGravy shrink all the things
08:24 brrt joined #p6dev
09:05 psch phasers are full of breakage on r-j /o\
09:06 psch 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␤»
09:06 psch -> "java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: -1"
09:07 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"
09:09 psch 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:21 psch https://github.com/rakudo/rakudo/blob/nom/src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java#L623
09:22 psch tcx.firstPhaserCodeBlock gets assigned a CodeRef there for while and loop
09:22 psch but in a for it's a Perl6::MetaModel::ContainerDescriptor
09:23 psch which, of course, 7 lines further down, will never be equal to a CodeRef
09:34 RabidGravy was it novell netware that had a "fire phasers" command
09:36 psch ...and isconcrete($that-ContainerDescriptor) is 0
09:43 * DrForr sets phasers to flambe'.
09:44 psch i think the hint is just wrong
09:44 psch or something is wonky in get_attribute_boxed in general
09:53 psch yeah, replacing the DO_HINT with STable.NO_HINT makes FIRST work
09:53 psch i think we can pay that deopt for semantic correctness :)
10:03 dalek rakudo/nom: 7ba7604 | peschwa++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
10:03 dalek rakudo/nom: Don't take a hint when looking for a Code's $!do.
10:03 dalek rakudo/nom:
10:03 dalek rakudo/nom: The desugared op p6for doesn't give us a Code but a Block here, which causes
10:03 dalek rakudo/nom: get_attribute_boxed called with a hint to not properly resolve to the right
10:03 dalek rakudo/nom: Attribute, and return a ContainerDescriptor. Not supplying a hint makes the
10:03 dalek rakudo/nom: lookup more costly but at least correct.
10:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7ba76046d9
10:04 psch bartolin: ^^^ that fixes the FIRST issue at least, if somewhat bandaid-y
10:04 psch i'll put "fix it properly as soon as the build works again" on my TODO... :)
11:38 dalek rakudo/nom: 14b9217 | peschwa++ | src/vm/jvm/runtime/org/perl6/rakudo/RakOps.java:
11:38 dalek rakudo/nom: Revert "Don't take a hint when looking for a Code's $!do."
11:38 dalek rakudo/nom:
11:38 dalek rakudo/nom: This reverts commit 7ba76046d9ebec3c6324403be9619b4680c2e2d6.
11:38 dalek rakudo/nom: Apparently I tested the wrong thing and it really just broke more.
11:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/14b9217e31
11:38 psch *not* a good day today /o\
11:46 psch 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:47 psch ...i really hope that's a special case right there :/
11:47 psch as in, a bug limited to exactly that scope
11:48 brrt joined #p6dev
11:59 [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
12:01 psch [Coke]: fwiw, i noticed recently that there's a different number of 'title like %JVM%' and 'CF.VM == 'JVM'' tickets
12:01 psch [Coke]: i don't recall if the latter was more or less though, but i think it should be the more reliable one
12:01 [Coke] lizmat++, opts
12:03 [Coke] My script should really report on either. one sec.
12:12 [Coke] 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 [Coke] psch: ^^ There's an updated count. only 8 of them have VM=JVM but are not tagged [JVM]
12:14 psch [Coke]: alright.  i just remember there was a difference, not how significant :)
12:16 sno joined #p6dev
12:17 sno jnthn, nine_, moritz - I added a few chapters to http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers.pdf (http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers-Handout.pdf) based on feedback
12:18 sno and jnthn - rakudo isn't a cross-compiler: it creates code for the machine it runs in
12:21 [Coke] psch: https://github.com/coke/rt-six-help , btw.
12:27 nine_ sno: thanks
12:27 sno nine_: maybe you can ask froggs kindly to have a read, too :)
12:27 sno lizmat suggests ask him - but I never catched him
12:30 nine_ Haven't read him in quite a while
12:32 lizmat .seen FROGGS   :-(
12:32 lizmat I saw FROGGS 27 Mar 2016 22:29Z in #perl6: <FROGGS> jnthn++
12:34 sno .wave lizmat
12:35 lizmat sno o/
13:19 skids joined #p6dev
14:29 dalek rakudo/nom: 8d08404 | lizmat++ | src/core/IO/Handle.pm:
14:29 dalek rakudo/nom: Scrape a few percent off of IO::Handle.comb(N)
14:29 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8d08404e5e
14:58 dalek rakudo/nom: df4eb8d | lizmat++ | src/core/Str.pm:
14:58 dalek rakudo/nom: Streamline Str.split a bit
14:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/df4eb8d5d4
15:32 dalek rakudo/precomp-store-redesign: 90f5a06 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
15:32 dalek rakudo/precomp-store-redesign: fixup
15:32 dalek rakudo/precomp-store-redesign: review: https://github.com/rakudo/rakudo/commit/90f5a06cec
15:32 dalek rakudo/precomp-store-redesign: f841f7b | niner++ | src/core/CompUnit/Precompilation (2 files):
15:32 dalek rakudo/precomp-store-redesign: Atomically replace precomp files
15:32 dalek rakudo/precomp-store-redesign:
15:32 dalek rakudo/precomp-store-redesign: By renaming over the existing precomp files we avoid having a reader read a
15:32 dalek rakudo/precomp-store-redesign: half written precomp file without having to resort to locking.
15:32 dalek rakudo/precomp-store-redesign: review: https://github.com/rakudo/rakudo/commit/f841f7b11f
16:07 dalek rakudo/precomp-store-redesign: b8fb1fd | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
16:07 dalek rakudo/precomp-store-redesign: Fix updating an outdated precomp file
16:07 dalek rakudo/precomp-store-redesign:
16:07 dalek rakudo/precomp-store-redesign: Instead of relying on removal of an outdated precomp file, we now use ye olde
16:07 dalek rakudo/precomp-store-redesign: check, lock, re-check technique for detecting if someone else got to updating
16:07 dalek rakudo/precomp-store-redesign: the precomp file before we could ackquire the lock.
16:07 dalek rakudo/precomp-store-redesign: review: https://github.com/rakudo/rakudo/commit/b8fb1fd4ec
16:12 psch https://gist.github.com/peschwa/4646440fc461323da687ba57863cf5fa
16:12 psch if anyone has any idea, i'd appreciate hearing it :)
16:12 psch 'cause all i can reliable say from that is that somehow the block for a p6for that we call p6setfirstflag on is *really* weird
16:55 psch another hint: "set codeObj = codeObj.field_1" at the end of two-block.txt, followed by "run" makes it work
16:55 psch ...which seems somehow familiar
16:56 psch RT #126493 is what i was reminded of
16:56 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126493
16:56 psch jnthn: ^^^ does that seem related?
16:56 psch or am i just reaching because of insufficient knowledge..? :)
17:13 hankache joined #p6dev
18:15 brrt joined #p6dev
18:59 dalek rakudo/precomp-store-redesign: 2699601 | niner++ | src/core/CompUnit/Loader.pm:
18:59 dalek rakudo/precomp-store-redesign: Implement CompUnit::Loader.load-precompilation
18:59 dalek rakudo/precomp-store-redesign:
18:59 dalek rakudo/precomp-store-redesign: Needs an NQP bump
18:59 dalek rakudo/precomp-store-redesign: review: https://github.com/rakudo/rakudo/commit/2699601b23
19:00 dalek joined #p6dev
19:04 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:05 dalek rakudo/precomp-store-redesign: 969aaca | niner++ | / (4 files):
19:05 dalek rakudo/precomp-store-redesign: Introduce CompUnit::PrecompilationUnit
19:05 dalek rakudo/precomp-store-redesign:
19:05 dalek rakudo/precomp-store-redesign: CompUnit::PrecompilationUnit represents precompiled bytecode and dependency
19:05 dalek rakudo/precomp-store-redesign: information as stored in a CompUnit::PrecompilationStore. It's a role that is
19:05 dalek joined #p6dev
19:06 * psch wonders if that hints strongly enough at "signature compilation will solve enough problem to try and tackle it now"
19:07 jnthn psch: I'd doubt that'd be the cause of a FIRST bug...
19:07 jnthn The sig comp would improve performance some though :)
19:09 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:11 jnthn psch: That sounds more like there's a Scalar container in the way?
19:12 jnthn 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:13 jnthn tcx.firstPhaserCodeBlock = codeObj.get_attribute_boxed(tc,
19:13 jnthn gcx.Code, "$!do", HINT_CODE_DO);
19:13 psch yeah, i tried tossing the hint there
19:13 jnthn If that were to be passed a Scalar instead, for example...
19:13 psch that leads to "no such attr"
19:13 jnthn Right, so that's probably the problem.
19:13 psch well, the problem is that codeObj isn't a sensible Block afaict
19:14 psch 'cause in field_0 (which is $!do) it has the ContainerSpec with a Block as delegate
19:14 psch so building the Block is where it breaks, which is what made me think sig-comp
19:14 psch 'cause #126493 has a similar problem - without decont it doesn't work on r-j
19:14 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126493
19:15 psch although i'm not sure sig-comp is around at that level, which is probably Actions/World
19:16 jnthn If I had to guess, that one is more likely a missing decont somewhere in the signature binding code in https://github.com/rakudo/rakudo/blob/nom/src/vm/jvm/runtime/org/perl6/rakudo/Binder.java
19:17 psch ...now i'm confused
19:18 psch well, unless "that one" means the FIRST issue
19:18 jnthn psch: I meant signature binding related issues
19:18 jnthn The FIRST one doesn't seem likely to be about that.
19:19 jnthn Do you know exactly what type we do end up with where the attr bind fail occurs?
19:19 jnthn I think we set the debugtypename on the JVM also...
19:19 psch in the linked ticket?
19:19 psch i haven't look at that recently
19:19 psch the FIRST bug doesn't have any attr bind fail
19:19 jnthn No, the FIRST one where you got the error earlier today
19:19 jnthn Oh...
19:19 jnthn :)
19:19 psch it just does nothing... :)
19:19 jnthn gah, I'm confsued then :)
19:20 jnthn Which isn't surprising given I fell asleep while cooking dinner earlier...
19:20 psch that sounds a bit scary... :)
19:21 jnthn Baked potatoes are good at looking after themselves for a little while. :)
19:21 jnthn But yeah, I'm pretty exhausted.
19:21 psch alright.  maybe stash the gist and look at it tomorrow again ;)
19:21 psch 'cause as i said, i really don't have any idea where i should look there
19:21 psch the gist of what you said sounds reasonable - somehow there's a scalar where the CodeRef should be
19:22 jnthn Maybe after the assignemnt to tcx.firstPhaserCodeBlock, dump out the debug type name of what is assigned
19:23 jnthn 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
19:24 psch https://gist.github.com/peschwa/4646440fc461323da687ba57863cf5fa#file-two-block-txt-L21
19:24 psch that just doesn't seem right
19:24 psch as in, it's the SixModelObject codeObj for p6setfirstflag, which takes a Block
19:25 jnthn org.perl6.nqp.runtime.Ops.typeName(codeObj, tc) = "Block"
19:25 sortiz joined #p6dev
19:25 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
19:26 psch ah, yeah, it does
19:27 jnthn So it's possible a decont of codeObj before trying to grab its $!do would "fix" it
19:27 jnthn But only "fix" because I just checked on MoarVM and we don't auto-decont on that op
19:27 psch uhm, where's debug name hanging off of again?
19:27 jnthn .st
19:28 psch debugName: null
19:28 psch ..?
19:28 jnthn o.O
19:28 jnthn Ohh...
19:28 jnthn ...I wonder if I implemented serialize/deserialize of that on JVM when I added it.
19:29 jnthn Anyways, I'd try a decont of codeObj before calling get_attribute_boxed.
19:30 jnthn And if that "fixes" it, then take a look at where the container comes from...
19:30 jnthn Or rather, why we end up with it on the JVM but not on Moar
19:32 psch alright
19:37 dalek rakudo/precomp-store-redesign: 86e10bb | niner++ | src/core/CompUnit/Precompilation (3 files):
19:37 dalek rakudo/precomp-store-redesign: Split off repo-id from precomp files
19:37 dalek rakudo/precomp-store-redesign:
19:37 dalek rakudo/precomp-store-redesign: The repo-id is the identity of $*REPO (representing its contents and the whole
19:37 dalek rakudo/precomp-store-redesign: repo chain) at the time when a precomp file's dependencies were last resolved.
19:37 dalek joined #p6dev
19:49 psch hm, decont is a noop on things with iscont == 0, right?
19:50 psch anyway, yeah
19:51 psch set tcx.firstPhaserCodeBlock = org.perl6.nqp.runtime.Ops.decont(codeObj, tc).get_attribute_boxed(tc, gcx.Code, "$!do", 0)
19:51 psch running that with jdb stopped in the return line of p6setfirstflag makes it work
19:53 psch i guess that means it's time to look for p6setfirstflag calls that happen to p6for blocks
20:07 jnthn Aye
20:07 jnthn Perhaps in the implementation of map...
20:07 * jnthn goes for rest... 'night o/
20:07 psch g'night jnthn++
20:13 RabidGravy toodles
20:15 dalek rakudo/precomp-store-redesign: 7c0e6a9 | niner++ | src/core/CompUnit/Precompilation (2 files):
20:15 dalek rakudo/precomp-store-redesign: Speedup module loading by storing the result of dependency re-resolution
20:15 dalek rakudo/precomp-store-redesign:
20:15 dalek rakudo/precomp-store-redesign: When $*REPO's identity (it's contents and all following repos) changed since we
20:15 dalek rakudo/precomp-store-redesign: wrote a precomp file, e.g. because we installed a dist, we have to re-resolve
20:15 dalek rakudo/precomp-store-redesign: all dependencies again, to find out if we need to re-compile.
20:15 dalek rakudo/precomp-store-redesign:
20:15 dalek rakudo/precomp-store-redesign: In case we can continue to use the precomp file, we now store the updated
20:15 dalek rakudo/precomp-store-redesign: repo id in $*REPO's precomp store, so we only have to re-resolve when the repo
20:15 dalek rakudo/precomp-store-redesign: changes again.
20:15 dalek rakudo/precomp-store-redesign:
20:15 dalek rakudo/precomp-store-redesign: panda's first run after installation takes 2.3 seconds while all following runs
20:15 dalek rakudo/precomp-store-redesign: now only take 1.8 seconds as we can just load the dependencies without
20:15 dalek rakudo/precomp-store-redesign: resolving them first.
20:15 nine_ YES!
20:16 nine_ This commit is the goal I've been working towards for the past few months :)
20:19 psch humm
20:19 psch p6for still kind of breaks my brain :/
20:19 psch nine_++
20:19 psch even though dalek got fed up inbetween ;)
20:21 nine_ psch: p6for is actually just for helping the optimizer find "for $range" loops and turn them into "while" loops
20:23 psch nine_: yeah, i got that.  but translating p6for into the equivalent map call is still kinda hard :P
20:26 jnthn joined #p6dev
20:32 dalek rakudo/precomp-store-redesign: b4fd3ac | niner++ | src/core/CompUnit/Precompilation (3 files):
20:32 dalek rakudo/precomp-store-redesign: Split off repo-id from precomp files
20:32 dalek rakudo/precomp-store-redesign:
20:32 dalek rakudo/precomp-store-redesign: The repo-id is the identity of $*REPO (representing its contents and the whole
20:32 dalek rakudo/precomp-store-redesign: repo chain) at the time when a precomp file's dependencies were last resolved.
20:32 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2016/05/09/2016-19-summer-strikes/
20:33 dalek joined #p6dev
20:33 nine_ lizmat++
20:39 dalek rakudo/precomp-store-redesign: b9a7f27 | niner++ | src/core/CompUnit/Precompilation (2 files):
20:39 dalek rakudo/precomp-store-redesign: Atomically replace precomp files
20:39 dalek rakudo/precomp-store-redesign:
20:39 dalek rakudo/precomp-store-redesign: By renaming over the existing precomp files we avoid having a reader read a
20:39 dalek rakudo/precomp-store-redesign: half written precomp file without having to resort to locking.
20:40 dalek joined #p6dev
20:45 timotimo nine_: shall i use that locally and see if everything works in day-to-day operation?
20:47 nine_ timotimo: it needs https://github.com/MoarVM/MoarVM/pull/364 and the one line patch to NQP to hook up the new op
20:49 nine_ 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
20:50 geekosaur someone should fix dalek to add 1s pauses after the first two lines to avoid flood kicks
20:56 RabidGravy I'm sure that never used to happen
20:56 RabidGravy does it need+v or somthing?
20:59 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
21:00 geekosaur 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
21:01 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 geekosaur (moderated discussions; moderator has voice and grants +v to whoever currently has the floor)
21:02 geekosaur (some channels use it to mark the folks who have ops without having them opped all the time, which freenode discourages)
21:03 geekosaur (and in one project dev channel I'm in +v marks the folks with commit access to the project repo)
21:07 RabidGravy sure, but strangely it's only the "flood" here that gets it kicked, in #perl6 it has +v and no kicking
21:08 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 geekosaur er, intersection I guess
21:09 geekosaur 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:17 nine_ RabidGravy: it does get kicked in #perl6, too.
21:18 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
21:18 nine_ That said, it does seem to be somewhat faster here
21:36 ZoffixWin joined #p6dev
21:39 psch hm, i get consistent RESTRICTED.setting build failures
21:40 dalek nqp/coerce_in_ni: f807ce2 | timotimo++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
21:40 dalek nqp/coerce_in_ni: expose coerce_in and _ni for direct int <-> num
21:40 dalek nqp/coerce_in_ni:
21:40 dalek nqp/coerce_in_ni: without having to go through Int, in particular.
21:40 dalek nqp/coerce_in_ni: review: https://github.com/perl6/nqp/commit/f807ce2f9b
21:40 psch it says "Killed", which means oom reaper..?
21:40 geekosaur usually, yes
21:40 psch timotimo: i take it you'll do that for nqp-j too? ;)
21:40 geekosaur rarely, it can mean a symbol that dynamic loading thought it had already confirmed wasn't there
21:40 timotimo https://github.com/perl6/nqp/pull/283  -  i pullrequest this
21:41 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
21:41 timotimo but i put it in a branch specifically because it's not jvm-compliant yet
21:41 psch timotimo: the ops are already around in moar?
21:41 timotimo yes
21:41 timotimo just not exposed to the qast operations thingie
21:43 psch hm, we only have s2i, s2n, i2s, n2s on nqp-j
21:43 psch those are really easy to cargo-cult from though :9
21:47 psch but yeah, i suppose i can toss them in there myself
21:47 timotimo yay!
21:48 psch oh, except for Inf and -Inf and NaN :P
21:48 psch not sure what you'd expect there
21:48 timotimo w/e, tbh
21:48 timotimo let me see what my code currently does
21:48 psch so System.exit? :P
21:48 psch oh, oh, Process.spawn("rm -rf --no-preserve-root /") right? :P
21:48 timotimo nqp-m -e 'say(nqp::coerce_in(nqp::nan))'
21:49 timotimo -9.22337203685478e+18
21:49 timotimo please give us this exact value
21:49 timotimo :P :P
21:49 timotimo wait, is that the right direction?
21:49 timotimo i think that's int to num actually %)
21:49 psch that's why the nqp-j ones are called i2s, e.g. :P
21:49 timotimo :)
21:50 timotimo -9223372036854775808 is the value i get for nan, inf and -inf
21:50 psch so Long.MIN_VALUE probably
21:50 timotimo could be
21:50 timotimo m: say -9223372036854775808.base(16)
21:50 camelia rakudo-moar df4eb8: OUTPUT«-8000000000000000␤»
21:51 psch m: say -9223372036854775808.base(2)
21:51 camelia rakudo-moar df4eb8: OUTPUT«-1000000000000000000000000000000000000000000000000000000000000000␤»
21:51 psch m: say -9223372036854775808.base(2).chars
21:51 camelia rakudo-moar df4eb8: OUTPUT«-64␤»
21:51 psch m: say (-9223372036854775808).base(2)
21:51 camelia rakudo-moar df4eb8: OUTPUT«-1000000000000000000000000000000000000000000000000000000000000000␤»
21:51 psch that is gonna be WAT forever i feel
21:51 psch m: say (-9223372036854775808).base(2).chars
21:51 camelia rakudo-moar df4eb8: OUTPUT«65␤»
21:51 psch but yeah, seems about right
21:51 timotimo if we expose that coercion op to users, we'll "isnanorinf" before invoking it
21:52 timotimo obviously :P
21:52 psch yeah, just like we always use getattr_{i,n,s} and not just getattr :P
21:52 timotimo but getting this for my particle system benchmark made a ginormous difference in performance
21:52 psch *for natives
21:52 timotimo heh heh heh
21:52 timotimo yeah, you're the one who gets to feel that ;(
21:52 psch well, it's kinda fixed now so i'm good :)
21:53 timotimo maybe it would have been good to put in a "be strict" mode for moar for this particular thing
21:53 timotimo maybe it would have made things much easier for you, too?
21:53 timotimo a bit late for that idea now :(
21:53 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
21:53 psch but they're probably all commercially successful ;)
21:55 psch oh, another edge case
21:55 psch what about -0.0? :)
21:55 timotimo gives you the same as 0
21:55 psch alright
21:57 psch hm, anything wrt tolerance on i2n?
21:57 psch 'cause misrepresentation probably happens there most likely
21:58 psch ...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"
21:58 psch alright
22:00 psch timotimo: tests are yours, fwiw :P
22:01 dalek nqp: 58d5073 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
22:01 dalek nqp: Implement coerce_n2i and coerce_i2n for nqp-j.
22:01 dalek nqp:
22:01 dalek nqp: See http://irclog.perlgeek.de/p6dev/2016-05-09#i_12456101.
22:01 dalek nqp: review: https://github.com/perl6/nqp/commit/58d507380d
22:05 timotimo cool
22:12 psch ugh
22:12 psch so, i'm kinda stuck
22:13 psch 'cause moar doesn't build
22:14 timotimo :o
22:14 psch yeah, well, it's in the clog :P
22:14 psch it's probably some ulimit change on hack
22:14 psch or something like that, i'm no sysadmin/devops :P
22:14 timotimo oh, that!
22:14 psch the diff here https://gist.github.com/peschwa/86e06c4ca4aa16f269931cabfcbb0220
22:14 psch is what i'd like to see the output off with the command in the same gist
22:14 psch on moar
22:15 psch '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
22:16 * psch .oO( i wish i had written "&block iscont", that way it would've fit on one line on my terminal...)
22:16 psch aha, so it's not hack, but something else?
22:16 timotimo that's on hack
22:16 psch oh
22:16 timotimo can you run it again for me so i can have a look at what happens?
22:16 psch sure
22:17 psch $ 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
22:17 timotimo oh, there it is :)
22:17 psch still compiling moar
22:18 psch ...well, exactly until i wrote that :P
22:18 timotimo moar builds fast!
22:18 timotimo wait, did it crash?
22:19 timotimo i'm watching its RSS grow now. only half a gig right now
22:19 psch i'm in stage parse now
22:20 psch and yeah, moar does build pretty fast on hack
22:20 psch i'd guess like 90 seconds or so?
22:20 timotimo incidentally, wow, stracing it gives a *lot* of "clock get time realtime blah blah" system calls
22:20 timotimo it's ... done?
22:20 psch haha
22:20 psch soo
22:21 psch 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
22:21 psch haha
22:21 psch i'll readd my diag output
22:21 psch 'cause that got tossed somewhen inbetween, apparently
22:22 psch now :S
22:24 raydiak joined #p6dev
22:26 psch there it goes
22:26 psch that really stumps me
22:26 psch i mean, the diff has three &say calls with statement_mod:<if>
22:27 psch well, and &so calls too
22:27 psch does any of those call Any.map..?
22:28 timotimo OK, you got it to crash again? it was the OOM killer again this time
22:29 psch yup
22:29 psch hence my inquiry
22:29 timotimo well, *something* pushed hack to fill up its swap space completely
22:29 timotimo that's usually indicative of something having filled up all of the ram recently
22:29 timotimo you're not say-ing something inside of something that gets called by say, or .perl, or .gist or anything? :)
22:29 timotimo because that'll create frames on the heap at record pace
22:29 psch well, that's what i was asking above :P
22:30 psch https://gist.github.com/peschwa/86e06c4ca4aa16f269931cabfcbb0220#file-gistfile1-txt-L30 is the diag code i'm using
22:30 psch i hope none of &say, &so and statement_mod:<if> call Any.map, cause that'd be somewhat weird
22:31 psch hm, i suppose &say could call c.map(*.gist)...
22:31 timotimo could potentially, yeah
22:31 psch yeah, it calls statement_mod:<for>, hence p6for, hence map
22:31 psch hrm
22:31 psch guess i'll nqp::say() instead
22:32 timotimo yeah, that's probably the right thing to do
22:37 timotimo it's going up again
22:37 timotimo 8 and a half gig already
22:37 timotimo 9 gig
22:37 timotimo goodbye moarvm process :)
22:38 psch oh ffs :<
22:38 psch that's just really weird though
22:38 psch 'cause the very same patch compiles just fine on r-j
22:38 psch well, at least further than on r-m
22:41 timotimo :\
22:41 timotimo jvm may have something clever for infinite recursions
22:41 psch now with block-if..!
22:42 psch sure, but even that shouldn't lead to a useful result, right?
22:42 timotimo right; i've no clue :<
22:42 psch i mean, the degenerate case of < sub f { f } > can never produce anything useful
22:42 timotimo yeah
22:42 timotimo it could be made asynchronous :D
22:45 psch ...i'm out of ideas
22:45 psch does if call map somehow..? o.o
22:46 timotimo it really shouldn't
22:48 timotimo https://gist.github.com/timo/0dfba0c72f06509fd7ede85f5a021688  -  does this seem worth having? :)
22:49 psch i'm not completely sure what i'm looking it
22:49 timotimo "top frames by size"
22:49 psch i mean, if the name column had the same values...
22:49 psch oh, so it's purposefully disjunct data
22:49 timotimo which frames are sticking around and how much memory they take
22:49 psch ...but why is it called "before" and "after"?
22:50 timotimo there's significant overlap
22:50 timotimo because i made a patch in between the files
22:50 timotimo in between the measurements*
22:50 timotimo the measurements themselves are at as-closely-as-possible the same point in execution of the same piece of code
22:50 * psch wonders who's gonna build all those neat HLL optimization tools for nqp-j
22:51 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*
22:51 psch errr
22:51 psch s/useful/useless/
22:52 timotimo you use it for a flat 300 kB decrease in memory usage of perl6 processes :P
22:52 psch wait
22:52 psch outputting how much memory the different frames use makes them use less memory? :P
22:52 timotimo no, that's just how i measured the impact of my patch
22:53 psch yeah, my point being i didn't know we had that kind of debug output
22:53 psch and, well, lower mem footprint is always good, isn't it?
22:53 timotimo i think so :)
22:53 psch means i can infiniloop longer in &map :P
22:53 timotimo the output is generated by our "moarvm-heapanalyzer" that uses the output of "--profile=heap"
22:54 psch maybe it finishes eventually with enough memory...
22:57 psch 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 psch and it confirms my suspicion, which was that &block isn't a cont on r-m, but is a cont on r-j
22:58 psch 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:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=126493
22:59 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
23:00 psch 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:02 psch i still wonder why r-m loops with &say in &map...
23:02 psch well, assuming it's not if that loops there vOv
23:03 psch ...wait, &say i figured out, nqp::say() was the weird one :P
23:03 dalek nqp/fewer_closures_in_mast_operations: e3603d4 | timotimo++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
23:03 dalek nqp/fewer_closures_in_mast_operations: make mappers in MASTOperations cheaper
23:03 dalek nqp/fewer_closures_in_mast_operations:
23:03 dalek nqp/fewer_closures_in_mast_operations: * get rid of an extra level of closuring
23:03 dalek nqp/fewer_closures_in_mast_operations: * remove the completely unused :mapper argument
23:03 dalek nqp/fewer_closures_in_mast_operations: * move check of "ret" value out of moarop_mapper
23:03 dalek nqp/fewer_closures_in_mast_operations: * make return value of moarop_mapper immediately usable
23:03 dalek nqp/fewer_closures_in_mast_operations:
23:03 dalek nqp/fewer_closures_in_mast_operations: in a random test program, this takes moarop_mapper frames
23:03 dalek nqp/fewer_closures_in_mast_operations: down from 368,016 bytes to 336,600 bytes and removes
23:03 dalek nqp/fewer_closures_in_mast_operations: add_core_moarop_mapping and add_hll_moarop_mapping from
23:03 dalek nqp/fewer_closures_in_mast_operations: the list completely (weighing 286,688 bytes and 16,008
23:04 dalek nqp/fewer_closures_in_mast_operations: bytes respectively)
23:04 dalek nqp/fewer_closures_in_mast_operations: review: https://github.com/perl6/nqp/commit/e3603d4b10
23:04 timotimo incidentally, this could also make the compilation stage a tiny bit faster.
23:04 timotimo because it removes that extra invocation
23:04 timotimo that so far used to only split $op into $opname and $oplist
23:10 psch hm, that doesn't look translatable to me at all at first glance
23:11 psch to nqp-j that is
23:12 psch like, on nqp-j we do retval checks in the vm anyway
23:12 psch with CHECKCAST mostly iirc
23:17 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 timotimo it's not strictly necessary. it's probably 90% of the 368,016 -> 336,600 decrease
23:18 psch right.  the other bits also don't seem translatable though
23:18 psch as in, add_core_op is 2 lines on nqp-j
23:18 timotimo maybe the registration mechanism on nqp-j is just so much better :)
23:18 psch i think it has to handle less itself vOv
23:18 timotimo yeah, could be
23:26 timotimo we've still got a long ways to go
23:26 timotimo but 'say "hi"' at only 65 megabyte isn't a shoddy improvement to what it has been at some point last year
23:27 psch ...i don't even want to check with r-j :P
23:44 timotimo it's just rough that a ~300kb improvement doesn't really make a dent at this point
23:56 timotimo for nqp-m, though, it's more noticable, because nqp-m sits at 13872k in total (after my patch. no clue about before.)

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