Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-06-12

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 lizmat joined #perl6-dev
01:48 ilbot3 joined #perl6-dev
01:48 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
03:08 skids joined #perl6-dev
03:16 awwaiid joined #perl6-dev
05:29 bartolin oops, yesterday a typo managed to sneak into jvm specific code: https://github.com/rakudo/rakudo/pull/784
07:39 dalek rakudo/nom: f060da0 | bartolin++ | src/core/control.pm:
07:39 dalek rakudo/nom: Fix typo in JVM specific code
07:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f060da0673
07:39 dalek rakudo/nom: 7fabb57 | niner++ | src/core/control.pm:
07:39 dalek rakudo/nom: Merge pull request #784 from usev6/patch-1
07:39 dalek rakudo/nom:
07:39 dalek rakudo/nom: Fix typo in JVM specific code
07:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7fabb5748d
08:41 RabidGravy joined #perl6-dev
09:13 cognominal joined #perl6-dev
09:35 [Tux] O...M...G... !!!
09:35 [Tux] This is Rakudo version 2016.05-103-g7fabb57 built on MoarVM version 2016.05-18-g1339332
09:35 [Tux] test            17.581
09:35 [Tux] test-t           9.785
09:35 [Tux] csv-parser      21.295
09:36 [Tux] Who is to receive some beer?
09:37 nine It is really happening!
09:49 bartolin wow, lizmat++
09:58 tadzik :o
09:58 tadzik lizmat++
09:58 AlexDaniel joined #perl6-dev
10:01 RabidGravy Ooooog
10:02 nine @s@s@s @s1qa23x44444444@s.@sp@s[@s;}"
10:02 nine Ooops...sorry, cleaning keyboard
10:07 RabidGravy so the 25% speed-up is nice to have in the back pocket, I think I'd better be testing all the modules against this
10:28 stmuk_ I might have to rewrite my YAPC talk "Lying with Benchmarks - Perl 6 is Faster!" :-(
10:35 lizmat sorry stmuk_   :-)
10:51 [Tux] stmuk_, you could do as I did: make the performance slide dynamic, so hitting that slide is always up-to-date :)
11:14 cognominal joined #perl6-dev
11:24 dalek rakudo/nom: 6e62c40 | lizmat++ | src/core/Mu.pm:
11:24 dalek rakudo/nom: Give Mu.BUILD_LEAST_DERIVED the same treatment
11:24 dalek rakudo/nom:
11:24 dalek rakudo/nom: Not sure how this will affect performance, but it seemed like the
11:24 dalek rakudo/nom: right thing to do in light of the performance gain that the
11:24 dalek rakudo/nom: Mu.BUILDALL work gave us.
11:24 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6e62c409bf
11:43 jnthn lizmat: It'll make mixins faster, if you're looking for how to exercise it ;)
11:43 lizmat runtime mixins you mean ?
11:45 jnthn Yes
11:45 jnthn .oO( there are others? :))
11:45 lizmat ok, I'll try some
11:45 jnthn (I call `class Foo does Bar { }` composition rather than mixing it, because the semantics are rather different.)
12:03 [Tux] joined #perl6-dev
12:09 lizmat jnthn: why is BUILDALL taking *@ and not doing anything with it ?
12:09 lizmat is this some interface thing I don't know about ?
12:09 cognominal joined #perl6-dev
12:09 lizmat actually, same for bless ?
12:15 dalek rakudo/nom: c6faf9b | lizmat++ | src/core/Iterable.pm:
12:15 dalek rakudo/nom: Streamline Iterator.flat
12:15 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c6faf9bf4e
12:20 jnthn Yeah, that Parent{ ... } interface we're not supporting yet
12:20 jnthn Will need to do that at some point...
12:21 lizmat until then, I can take it out of bless and BUILDALL ?
12:22 lizmat or perhaps turn bless into a multi ?
12:23 [Tux] This is Rakudo version 2016.05-104-g6e62c40 built on MoarVM version 2016.05-18-g1339332
12:23 [Tux] test            17.559
12:23 [Tux] test-t           9.734
12:23 [Tux] csv-parser      20.887
12:24 [Tux] just for continuous feedback
12:30 RabidGravy well I've just tested 55 modules with the latest and it all works :) (probably covers about 10% of the ecosystem with dependencies)
12:31 lizmat *phew*
12:34 RabidGravy though it hasn't made any difference to the length of time that takes (however I can't remember how many new modules and what changes to the numbers of tests since I last ran it)
12:45 dalek rakudo/nom: d76c3fb | lizmat++ | src/core/DateTime.pm:
12:45 dalek rakudo/nom: Fix positional in call to bless: it should be named
12:45 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d76c3fb30f
12:59 dalek rakudo/nom: 4179bdc | lizmat++ | src/core/Mu.pm:
12:59 dalek rakudo/nom: Make object construction again 1.8x faster
12:59 dalek rakudo/nom:
12:59 dalek rakudo/nom: It turns out that Mu.bless and Mu.BUILDALL were taking positional
12:59 dalek rakudo/nom: parameters that were never actually given (apart from one arguably
12:59 dalek rakudo/nom: faulty spectest).  This in turn caused flattening on an empty array
12:59 dalek rakudo/nom: to be performed.  And then get passed to BUILDALL, which in turn
12:59 dalek rakudo/nom: didn't do anything with it.  According to spec, bless should take
12:59 dalek rakudo/nom: autovivifying type objects, but this has not been implemented.
12:59 dalek rakudo/nom:
12:59 dalek rakudo/nom: Until that happens, it would seem we can use the performance boost
12:59 dalek rakudo/nom: of not allowing positionals towards Mu.bless and Mu.BUILDALL, instead
12:59 dalek rakudo/nom: of silently eating them and not doing anything with them.
12:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4179bdc7dc
12:59 lizmat [Tux]: ^^^  :-)
13:00 lizmat probably won't make it below 9 yet, but there's hope  :-)
13:01 dalek roast: f1dcc25 | lizmat++ | S12-construction/construction.t:
13:01 dalek roast: Fix faulty test of .bless
13:01 dalek roast: review: https://github.com/perl6/roast/commit/f1dcc254cf
13:02 dalek roast/6.c-errata: 93f6013 | lizmat++ | S12-construction/construction.t:
13:02 dalek roast/6.c-errata: Fix faulty .bless test
13:02 dalek roast/6.c-errata: review: https://github.com/perl6/roast/commit/93f6013d20
13:10 [Tux] This is Rakudo version 2016.05-107-g4179bdc built on MoarVM version 2016.05-18-g1339332
13:10 [Tux] test            17.101
13:10 [Tux] test-t           9.734
13:10 [Tux] csv-parser      20.817
13:14 lizmat hmmm... that's eh, disappointing ?
13:18 [Tux] timotimo, I realized after I counted my return statements, that the returns are most likely not the hot-spots that are still causing a slowdown: it is much more likely my "next" statements are the cause of slowness
13:37 Zoffix left #perl6-dev
13:45 psch nine: from the looks of it, the way i'm stuffing the J::Class into $*W doesn't carry into the EVALs
13:45 psch which i take it means we get a new World with each EVAL
13:52 dalek rakudo/nom: 51e1a27 | lizmat++ | src/core/List.pm:
13:52 dalek rakudo/nom: Make List.from-slurpy-flat about 10% faster
13:52 dalek rakudo/nom:
13:52 dalek rakudo/nom: Which directly translates to the same efficiency gain for any call
13:52 dalek rakudo/nom: to a sub/method with a slurpy array.
13:52 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/51e1a27509
14:09 Ven_ joined #perl6-dev
14:44 psch also of note, the LinkageError apparently happens due to the second EVAL
14:44 psch probably because we've finished writing the J::Class for the first one already and loaded it afterwards
14:45 psch which means putting the different EVALs into the same class can't work with the current structure at all, unless i'm missing something
14:54 nine psch: yes, every compilation unit (including EVALs) gets its own world. Part of my EVAL fix was to share specific data between those worlds
14:56 psch right, yeah, i remember bits of that
14:56 psch ah, so that'd also be the peg to hang the JCLASS on, assuming i'm wrong and stuffing multiple EVALs into the same JCLASS works
15:05 timotimo [Tux]: you are right. my over-simplified test with and without a useless next give a difference from 10s to 17s
15:06 timotimo er, i mean, you could be right; next is slow, but i can't know if that's your bottleneck or not
15:11 [Tux] his is Rakudo version 2016.05-108-g51e1a27 built on MoarVM version 2016.05-18-g1339332
15:11 [Tux] test            17.157
15:11 [Tux] test-t           9.584
15:11 [Tux] csv-parser      21.411
15:11 [Tux] timotimo, I'm sure it is
15:12 timotimo it's probably not possible to rewrite your code to use if/else instead of skipping with else?
15:13 timotimo just for performance test, i mean
15:28 lizmat timotimo: I looked at doing that, but it's not simple  :-(
15:28 timotimo yeah, i feared that
15:31 dalek rakudo/nom: 6bcf4dd | lizmat++ | src/core/Junction.pm:
15:31 dalek rakudo/nom: Make Junction grok completely empty List states
15:31 dalek rakudo/nom:
15:31 dalek rakudo/nom: While attempting to reduce allocations for empty Lists, I found that
15:31 dalek rakudo/nom: the Junction code could not cope very well with an unallocated
15:31 dalek rakudo/nom: $!reified in its states List.  This is now a thing of the past.
15:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6bcf4dddc2
15:31 timotimo ooooh
15:31 timotimo good catch
15:32 jnthn Hm, I can likely speed up next during my hacking time next week, given I've been working on return :)
15:32 Ven_ joined #perl6-dev
15:32 dalek rakudo/nom: 7584139 | lizmat++ | src/core/List.pm:
15:32 dalek rakudo/nom: Make List.from-slurpy not allocate when not needed
15:32 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7584139fa9
15:33 * jnthn has nearly finished a blog post
15:33 jnthn Should get it finalized and posted after making dinner. :)
15:34 timotimo speed up next next?
15:34 lizmat ++jnthn
15:37 cognominal jnthn++
15:38 mst (((jnthn)))++
15:47 [Tux] jnthn++
15:47 [Tux] lizmat++
15:59 psch i'm thinking that $*CODEREFS is actually what should be shared via mast_frames
16:00 psch ...i'm *not* sure that's fully thought out or sensible, though
16:03 FROGGS joined #perl6-dev
16:04 FROGGS o/
16:07 timotimo o/
16:08 FROGGS ummm
16:08 FROGGS what spectest target should I use?
16:08 FROGGS m-spectest        m-spectest5       m-spectest6       m-spectest_full5  m-spectest_full6
16:09 mst one of those
16:09 mst probably
16:09 mst </not-helping>
16:09 FROGGS heh
16:09 timotimo i usually just m-spectest
16:09 timotimo or rather, spectest
16:09 FROGGS k
16:18 nine FROGGS: spectest passed, test passed, panda's bootstrap works and panda install Task::Star is going on just fine :)
16:19 timotimo that sounds encouraging
16:20 nine Successfully installed Task::Star
16:22 [Tux] next is -Duselongdouble support?
16:22 FROGGS nine: with my patch?
16:22 * [Tux] hides
16:23 timotimo [Tux]: as i may have said before, it requires that piece of design in moarvm that'll allow things longer than 64bit in registers
16:23 [Tux] someone suggested a plugin might do it
16:23 nine FROGGS: yes
16:23 FROGGS nine: awesome! thanks for testing :o)
16:23 [Tux] module/... whatever
16:23 FROGGS nice to have something to commit after several months :o)
16:23 nine FROGGS: your patch and merged rt128156_fix_precomp_deps_validation branch which should fix time stamp issues on file systems from the stone age
16:24 nine FROGGS: that patch takes a huge load off my shoulders :)
16:24 timotimo in theory, yeah. you'll have to treat every long double to be placed "behind" a pointer, and have a C function written for every kind of operation you want to do on long doubles
16:24 timotimo that will work
16:24 timotimo but it'll also suck :)
16:28 dalek rakudo/nom: d0a0016 | FROGGS++ | src/core/CompUnit/PrecompilationRepository.pm:
16:28 dalek rakudo/nom: fix content of .precomp/.../*.rev-deps files
16:28 dalek rakudo/nom:
16:28 dalek rakudo/nom: These files contained wrong ids, namely several occurrences of the id of
16:28 dalek rakudo/nom: the file itself.
16:28 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d0a00164e9
16:29 timotimo i wonder if this has a performance implication, too? like, at all?
16:31 FROGGS hmmm, my imagination is not good enough to guess
16:34 dalek rakudo/nom: 491af60 | niner++ | src/core/CompUnit/Precompilation (3 files):
16:34 dalek rakudo/nom: Fix precomp dependency checks on file systems with coarse timestamps.
16:34 dalek rakudo/nom:
16:34 dalek rakudo/nom: Replace fragile timestamp check by checksums for deciding whether a
16:34 dalek rakudo/nom: precompiled dependency is still the same.
16:34 dalek rakudo/nom:
16:34 dalek rakudo/nom: Many thanks to pmurias++ for suggesting using a hash!
16:34 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/491af6034d
16:34 nine With these two patches, rt128156 should hopefully be history :)
16:42 teatime joined #perl6-dev
16:46 dalek rakudo/nom: bca0daa | lizmat++ | src/core/List.pm:
16:46 dalek rakudo/nom: Faster List.from-slurpy-onearg (from 20% upto 4x)
16:46 dalek rakudo/nom:
16:46 dalek rakudo/nom: Which directly translates to same performance gains for the
16:46 dalek rakudo/nom: (+@list) signature: 4x for no parameters, to 20% for exactly 1.
16:46 dalek rakudo/nom: More than one parameter is about 2.5x faster.
16:46 dalek rakudo/nom:
16:46 dalek rakudo/nom: - no longer revert to from-slurpy for cases != 1
16:46 dalek rakudo/nom:   We've already done some of the work, why do it again?
16:46 dalek rakudo/nom: - no longer need to create a Perl 6 level capture
16:46 dalek rakudo/nom:   Since we don't need to pass it on.
16:46 dalek rakudo/nom: - return bare List object for no parameters
16:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bca0daa04f
16:48 lizmat no idea how this is going to affect test-t, probably not
16:49 timotimo cool!
16:53 sno joined #perl6-dev
16:54 dalek rakudo/nom: 054a54a | (Daniel Green)++ | src/Perl6/Grammar.nqp:
16:54 dalek rakudo/nom: Fix for RT #128306
16:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/054a54aa22
16:54 dalek rakudo/nom: 8430f07 | lizmat++ | src/Perl6/Grammar.nqp:
16:54 dalek rakudo/nom: Merge pull request #785 from MasterDuke17/RT128306
16:54 dalek rakudo/nom:
16:54 dalek rakudo/nom: Fix for RT #128306
16:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8430f07a28
16:54 timotimo oh, synopsebot6 should probably hang out here, too
17:02 [Tux] This is Rakudo version 2016.05-115-g8430f07 built on MoarVM version 2016.05-18-g1339332
17:02 [Tux] test            17.425
17:02 [Tux] test-t           9.585
17:02 [Tux] csv-parser      21.475
17:02 timotimo that's just 0.001 difference from the previous message
17:03 lizmat [Tux] : yeah, no (+list) sigs in Text::CSV
17:03 timotimo fair enough
17:03 lizmat should be noticeable in other places, though
17:04 timotimo yeah, many things in the setting have those
17:04 CQ joined #perl6-dev
17:15 lizmat afk&
17:20 dalek roast: 716b94f | FROGGS++ | S10-packages/precompilation.t:
17:20 dalek roast: add another test for RT #128156
17:20 dalek roast: review: https://github.com/perl6/roast/commit/716b94f7ff
17:21 CQ who runs dalek? would be helpful to have RT#s show up as URLs instead of IRC channels ... : )
17:22 timotimo that's what synopsebot6 can do :)
17:23 timotimo also, "showing up as irc channels" is probably your irc clients' fault :)
17:23 CQ timotimo: sure, anything with a #something is a channel...
17:24 timotimo i'm not so sure about that :)
17:24 CQ timotimo: I mean on my irc client (chatzilla)
17:24 synopsebot6 joined #perl6-dev
17:24 timotimo OK
17:52 cognominal joined #perl6-dev
17:56 * jnthn finally got around to blogging: https://6guts.wordpress.com/2016/06/12/grinding-out-performance-improvements/
17:56 mst woo
17:56 mst let's see if I can understand one word in three
18:01 masak "Do 5 small improvements that win an average of 1% each, and it adds up to a more satisfying 5% improvement." -- only just
18:01 masak m: say 1 - .99 ** 5
18:01 camelia rakudo-moar 8430f0: OUTPUT«0.0490099501␤»
18:02 masak or "not quite", rather
18:02 jnthn Which rounds up to 5% :P
18:03 masak yeah, yeah :)
18:03 masak actually, it was more the "adds up" part that bothered me ;)
18:04 jnthn Maybe "combine" woulda been better :)
18:04 masak "multiply up" :P
18:04 jnthn But hey, I'm a compiler hacker, not a statistician :P
18:05 * masak .oO( you've sped things up significantly -- how *dare* you be off by a factor of .02!? ) :P
18:07 masak hm, is it `package Main;` in Perl 5, or `package main;`?
18:09 geekosaur the latter
18:11 masak jnthn: though I'm not really sure why you're switching packages at all there -- maybe out of a sense of fair comparison, because the Perl 6 class is block-scoped?
18:12 jnthn masak: Clarity mostly
18:13 masak anyway, it should probably be `main` so as not to needlessly confuse those faithful p5 readers out there ;)
18:14 jnthn Fine, but I'm not going to take the time to re-measrue :)
18:16 mst for clarity
18:16 mst package A {
18:16 mst ...
18:16 mst }
18:16 mst would correspond nicely and save you the second package line
18:16 * masak .oO( turns out lower-case `m` is 10% faster than upper-case `M`... ) o.O
18:16 masak what mst++ said
18:16 masak but yeah, no need to re-measure
18:17 jnthn mst: Hm, is that a recent-ish addition?
18:17 mst jnthn: no
18:17 masak 5.18 or so?
18:18 mst 5.14
18:18 masak oh wow
18:18 jnthn Time flies :)
18:19 jnthn Anyways, it can stay as it is in the post.
18:20 jnthn Took me weeks to find the energy to blog at all :P
18:20 masak jnthn++ # I know how that feels
18:22 jnthn And, fwiw, I'm not doing Perl 5 comparisons to see "whose ahead" rather than to give a sense of "is Perl 6 even in the ballpark"
18:25 CQ jnthn: thanks for the blogposts, they're fun and interesting reading, even if sometimes my comprehension levels at 30% if you're off to the depths of an issue : )
18:27 mst jnthn: that's what I took it as
18:29 * masak .oO( "whose alot" )
18:30 masak jnthn: thanks for the blog posts. I always understand everything perfectly :P
18:31 * masak .oO( that's only 95.09900499% true )
18:34 jnthn .oO( I look forward to analizing your next blog post too :P )
18:35 * masak .oO( OH NOES WUT HAV I D... hey wait, that actually sounds rather nice )
18:38 b2gills Can someone prune some of the branches on the rakudo repository? I mean some have parrot in the name. ( there are over 150 branches )
18:43 timotimo tbh, i would have liked to see perl6 before, perl6 after and perl5 cycle counts for small, medium, big loops ... but that'd take ages :)
18:43 timotimo that should give slightly linear curves where you could easily-ish see startup cost and per-loop cost
18:44 masak timotimo: well volunteered!
18:45 timotimo hm. if jnthn gives me exact-ish commit ids for this work in question, that would be very doable
18:47 jnthn timotimo: I linked most of the commits from the post :)
18:52 FROGGS jnthn: a few hours ago CompUnit::PrecompilationRepository.load's return type has changed... (from CU to List)
18:52 FROGGS jnthn: are we allowed to do that wrt policy?
18:54 timotimo oh
18:55 edehont joined #perl6-dev
19:21 moritz FROGGS: is it tested in roast? used in the ecosystem?
19:21 moritz if not, I think we can
19:21 FROGGS used in doc/htmlify.p6
19:23 FROGGS but does not seem to be tested in roast
19:27 moritz I think the build process on hack still uses some older rakudo
19:27 moritz 2016.04
19:28 moritz star-m: say 'version?'
19:28 camelia star-m 2016.01: OUTPUT«version?␤»
19:29 FROGGS [20:31] <dogbert17> interesting htmlify.p6 has suddenly stopped working
19:29 FROGGS that's why I am asking
19:30 moritz right
19:31 dogbert17 joined #perl6-dev
19:32 dogbert17 it was this which made me suspicious: https://travis-ci.org/perl6/doc/builds/137088856
19:32 moritz if I add [0], it should work with both old and new code, right?
19:33 FROGGS most likely, yes
19:34 moritz push'd
19:34 moritz travis will tell me :-)
19:34 FROGGS moritz++
19:34 dogbert17 moritz++
19:41 lizmat hmmm.... looks like something broke Inline::Perl5
19:42 lizmat Too many positionals passed; expected 2 arguments but got 3
19:42 lizmat in method new at /Users/liz/Github/panda/.panda-work/1465760385_4/lib/Inline/Perl5.pm6 (Inline::Perl5) line 949
19:43 lizmat ah, looks like *I* broke it
19:49 jnthn FROGGS: If it's not tested in roast, then technically yes it's allowed... Also, the compunit repo stuff is all still a tad up in the air, afaik
19:56 lizmat fixed in Inline::Perl5
19:56 lizmat FROGGS nine: this is probably not news to you, but t/spec/S10-packages/precompilation.t fails atm
20:16 TimToady joined #perl6-dev
20:21 FROGGS lizmat: this is news to me
20:21 FROGGS lizmat: head passes here
20:22 FROGGS ohh wait...
20:22 dalek roast: 8f34231 | FROGGS++ | packages/RT128156/ (4 files):
20:22 dalek roast: add missing test files
20:22 dalek roast: review: https://github.com/perl6/roast/commit/8f342316e8
20:22 * FROGGS facepalms
20:23 lizmat aha!  :-)
20:23 FROGGS lizmat: now it should pass /o\
20:23 * lizmat checks
20:28 lizmat FROGGS: clean now, indeed  FROGGS++
20:29 FROGGS \o/
20:33 FROGGS gnight #perl6-*
21:02 lizmat RT #128306
21:02 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128306
21:04 jnthn lizmat: There was a proposed MoarVM patch to fix that; I rejected it because it took the wrong approach, but suggested what might be a better way.
21:05 lizmat yeah, and I merged it  :-)
21:05 lizmat 054a54aa22d05554bbc1be to be precise
21:05 lizmat I started working on the P6W already
21:08 jnthn lizmat: ah, I missed that :)
21:08 * jnthn blames the football :)
21:10 nine lizmat: your Inline::Perl5 fix looks fine :) Tests well and all the examples from my talks seem to continue to work
21:11 lizmat I was wondering if you could take it further, to remove posiitionals from .new as well
21:12 lizmat I think it will give a significant performance boost
21:12 lizmat if you're creating a lot of objects, that is
21:13 nine lizmat: you mean from Mu's .new?
21:13 lizmat no, from Perl5Package.new (line 726)
21:13 lizmat and Perl5Parent.new, (line 949)
21:14 nine No, I need to be able to pass those on to the Perl 5 class' constructor. And those take positionals very often.
21:15 lizmat ok, I figured something like that, that's why I didn't do it right away  :-)
21:15 nine If anyone has a better idea for how to structure the code in PrecompilationRepository so .load doesn't have to return ($handle, $checksum), I'm all ears.
21:16 lizmat can't $checksum be a method on $handle ?
21:17 nine It could, but it just doesn't feel right. It's not a property of a CompUnit::Handle but of a PrecompilationUnit
21:17 lizmat so perhaps $handle is an attribute of PrecompilationUnit ?
21:17 nine which is a precomp file (consisting of bytecode and serialized objects) + its dependency information.
21:19 nine Hmm...having PrecompilationStore.load return a PrecompilationUnit. That suddenly doesn't sound as bad as the first two time I've thought about it.
21:19 jnthn Well, there's always returning some object with handle and checksum properties... :)
21:20 jnthn But yeah, the thing you load from a PrecompilationStore being a PrecompilationUnit sounds fairly right :)
21:26 nine Thanks :)
21:39 jnthn Sleep time...'night
21:40 lizmat gnight jnthn
21:43 timotimo gnite
21:59 dalek rakudo/nom: 5d49498 | lizmat++ | src/core/List.pm:
21:59 dalek rakudo/nom: Fixup List.sum
21:59 dalek rakudo/nom:
21:59 dalek rakudo/nom: - make sure we get a nice fail if it is a lazy list
21:59 dalek rakudo/nom: - don't allocate if it is and will be an empty list
21:59 dalek rakudo/nom: - streamline the addition loop
21:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5d494988c7
22:08 pochi joined #perl6-dev
22:10 timotimo lizmat: do you think a small check of the first value in a list and skipping first-concrete for min and max can enhance performance?
22:11 lizmat no firm idea
22:11 timotimo i have a piece of code where min takes a big chunk of total run time. it spends 63% of time inside cmp, but 10.8% in first-concrete
22:11 timotimo all in all, min is in second place by exclusive time, with only 9.17%, but its inclusive time is a whopping 49.8%
22:13 timotimo hm, it could also be min is responsible for find-best-dispatchee calls ... which the profiler sadly can't appropriately place in the call graph :(
22:14 lizmat timotimo: now I'm not sure which min / max you're talking about
22:14 timotimo the method in any-iterable-methods
22:16 lizmat would have to benchmark and profile
22:17 lizmat which made me just realize I have been hacking way too long today already  :-)
22:18 lizmat good night, #perl6-dev!
22:18 timotimo gnite!
22:18 timotimo thanks for your outstanding work today and always :)
22:24 timotimo hmm. how to output a stacktrace from nqp ...

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary