Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-11-05

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

All times shown according to UTC.

Time Nick Message
00:13 dalek rakudo/POSTBUILD_method: fdc90a2 | timotimo++ | src/Perl6/Metamodel/BUILDPLAN.nqp:
00:13 dalek rakudo/POSTBUILD_method: enable POSTBUILD to take part in object construction
00:13 dalek rakudo/POSTBUILD_method:
00:13 dalek rakudo/POSTBUILD_method: it will be called after everything else has been done. it'll
00:13 dalek rakudo/POSTBUILD_method: get the same arguments as the BUILD submethod, but things have
00:13 dalek rakudo/POSTBUILD_method: already been initialized, default values populated, ...
00:13 dalek rakudo/POSTBUILD_method: review: https://github.com/rakudo/rakudo/commit/fdc90a2e76
00:15 MasterDuke_ No such method 'map' for invocant of type 'NQPArray'
00:15 timotimo yeah, you'll have to use a for loop for that, or a while loop and nqp::iter
00:16 MasterDuke_ huh, it was a for, but i'll try the others
00:16 timotimo oh, perhaps it's accidentally a for loop in perl6 code?
00:17 timotimo if so, try and see what "for nqp::hllize($the-nqparray-in-question) { ... }" will do
00:17 timotimo if that makes it work, it could be enough to generate an QAST::Op( :op<hllize>, ... ) around the code you generate
00:18 MasterDuke_ thanks, i'll try that next
00:18 timotimo good luck. i'm off to bed very soon
00:19 MasterDuke_ later...
00:22 MasterDuke_ ah ha! success with binding and a while on an nqp::iterator!
00:23 MasterDuke_ timotimo++
02:00 seatek joined #perl6-dev
02:22 ggoebel joined #perl6-dev
07:54 RabidGravy joined #perl6-dev
08:19 lizmat Files=1151, Tests=53712, 216 wallclock secs (12.91 usr  3.64 sys + 1308.15 cusr 122.34 csys = 1447.04 CPU)
09:20 FROGGS joined #perl6-dev
09:38 FROGGS o/
09:46 lizmat FROGGS \o
10:16 dalek rakudo/nom: aa97f86 | lizmat++ | src/core/ (3 files):
10:16 dalek rakudo/nom: Introduce R:I:ShapeIndexIterator
10:16 dalek rakudo/nom:
10:16 dalek rakudo/nom: - a 5x faster way to generate indices for multi-dim arrays
10:16 dalek rakudo/nom: - let @a[2;2].keys use that
10:16 dalek rakudo/nom: - falls back to IntRangeIterator for single dimmed arrays
10:16 dalek rakudo/nom: - ignore shape if 1 dimmed and *, makes my @a[*] work, partly fixes RT #124502
10:16 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=124502
10:16 dalek rakudo/nom: - makes methods like .values, .kv, .pairs about 30% faster as well
10:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aa97f86d9b
10:20 dalek roast: cf300e4 | lizmat++ | S02-types/array-shapes.t:
10:20 dalek roast: Unfudge now passing test
10:20 dalek roast: review: https://github.com/perl6/roast/commit/cf300e4743
10:21 lizmat jnthn: hope it's ok to make my @a[*] work, or do you consider this to be 6.d material ?
10:56 MasterDuke joined #perl6-dev
11:01 MasterDuke timotimo answered a question i had yesterday, but it may not have been the right question. does the backtrace printing when you do --ll-exception happen in rakudo? and if so, where?
11:01 MasterDuke i thought i found it in the X::Comp role (in its gist method) in Exception.pm, but i can't seem to get that code to run, even pulling examples from roast that explicitly check for throws-like X::Comp
11:34 lizmat m: my @a[10] = 1,2,4...*; dd @a   # feels to me that this should just work ?
11:34 camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤  in block <unit> at <tmp> line 1␤␤»
11:34 lizmat m: my @a[10] = 42 xx *; dd @a   # as this ?
11:34 camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤  in block <unit> at <tmp> line 1␤␤»
11:42 MasterDuke also, 'say "thing: " ~ $_ for <my variable>" works, but 'say "thing: $_" for <my variable>' complains something like "no such method Stringy for type NQPMatch"
11:46 dogbert17 m: my Int @mat[2;2] is default(0) # is this on lizmat's fix list?
11:46 camelia rakudo-moar aa97f8: OUTPUT«===SORRY!=== Error while compiling <tmp>␤is default on shaped Array[Int] not yet implemented. Sorry. ␤at <tmp>:1␤------> fault(0) # is this on lizmat's fix list?⏏<EOL>␤    expecting any of:␤        constraint␤»
11:47 lizmat dogbert17: I'm primarily focused on making things faster
11:47 lizmat do you have a ticket number for that ?
11:47 dogbert17 lizmat: I know, but it was worth a shot
11:48 dogbert17 dunno if there's a ticket number to be honest, tries too look ...
11:51 dogbert17 didn't find any, OTOH I'm not a RT ninja :-)
11:51 lizmat please make one... I don't see a reason why that shouldn't work, as it should just be setting the descriptor, and shaped arrays share that with "normal" arrays
11:52 dogbert17 on the plus side, one of my scripts which uses 2d arrays have been running quite a bit faster with your recent fixes
11:52 dogbert17 I'll fix the RT
11:53 lizmat dogbert17: any idea how much faster ?
11:53 * lizmat likes independent benchmarks
11:54 dogbert17 real 6m17.384  user 6m16.172s with Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-13-g34c375a
11:55 dogbert17 I see that you have some supernew fixes, maybe I should rebuild and run again first
11:56 jnthn lizmat: Don't think making `my @a[*]` work is a problem...it's the test suite that defines the language, anyway. :)
11:57 dogbert17 give me a few mins, in the meantime https://gist.github.com/dogbert17/3069f8d880df27523aed42232d32d433
12:01 lizmat jnthn: ok
12:01 lizmat jnthn: opinions on my @a[10] = 42 xx * ?
12:02 jnthn I think I conservatively went with not having things that provide too many values from failing so as not to silently discard data in that case...
12:02 jnthn m: my @a[10] = 42 xx 10
12:02 camelia rakudo-moar aa97f8: ( no output )
12:02 jnthn m: my @a[10] = 42 xx *
12:02 camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤  in block <unit> at <tmp> line 1␤␤»
12:03 jnthn m: my @a[10] = 42 xx 9
12:03 camelia rakudo-moar aa97f8: ( no output )
12:03 jnthn m: my @a[10] = 42 xx 11
12:03 camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤  in block <unit> at <tmp> line 1␤␤»
12:03 jnthn Arguably we could decide not to whine based on is-lazy
12:04 jnthn Depends whether we see the convenience coming out ahead of "you asked me to complain if you constraints are broken"
12:06 lizmat well, the use-case I see where the size of the shaped array is disconnected from its initialization
12:06 lizmat my @a[$size] = 0 xx *
12:07 lizmat of course, in this case you could have said 0 xx $size, I know
12:07 lizmat but that was not the point  :-)
12:08 jnthn Well yes, the question is when there is a point :-)
12:08 jnthn (How often is initialization separated?)
12:09 jnthn m: my @a[10] Z= 0 xx *
12:09 camelia rakudo-moar aa97f8: ( no output )
12:09 jnthn Also you can always do that
12:09 jnthn m: my @a[3;3] Z= 1 xx *; say @a
12:09 camelia rakudo-moar aa97f8: OUTPUT«[[1 1 1] [1 1 1] [1 1 1]]␤»
12:09 lizmat well, as a data point: spectest passes if we don't die on a lazy iterator
12:09 jnthn Which even works without you knowing the number of dimensions :)
12:10 jnthn Yes, I'd only have encoded dying on that in the spectest if I'd expected us to always do so :)
12:11 lizmat fwiw, the performance burden on this would be minimal
12:12 lizmat basically, an extra iseq_i for each iteration, and an extra islt_i and istype at the end
12:12 jnthn Oh, I'm not worrying about performance
12:12 lizmat *is-lazy
12:12 jnthn Entirely about catching mistakes.
12:13 lizmat if the iterator is not lazy, it would die
12:13 lizmat $ 6 'my @a[10] = ^Inf; dd @a'
12:13 lizmat Array.new(:shape(10,), [0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
12:13 lizmat $ 6 'my @a[10] = ^11; dd @a'
12:13 lizmat Index 10 for dimension 1 out of range (must be 0..9)
12:13 dogbert17 lizmat: current standings, Real 4m38.345s, user 4m37.488s, This is Rakudo version 2016.10-176-gaa97f86 built on MoarVM version 2016.10-37-gf769569
12:13 jnthn Right, that's the question. Is laziness a good enough hint that we don't mind silently discarding data.
12:14 lizmat m: my @a; @a[1..10] = ^Inf; dd @a   # we do it here
12:14 camelia rakudo-moar aa97f8: OUTPUT«Array @a = [Any, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]␤»
12:16 jnthn *nod*
12:16 jnthn Yeah, there is precedent.
12:17 jnthn I think I'm OK with making it work on the sized array case too. Guess TimToady++ will backlog and cast a vote against if we're off on it. :)
12:18 jnthn my @a[2;2] = (1 xx *) xx *; # does this case work also?
12:21 lizmat i think it should
12:22 lizmat even ($++ xx *) xx *   :-)
12:25 jnthn Yes, if we're going to make my @a[10] = 1 xx * work then we should do the same for multi-dim
12:25 jnthn I think we can enforce that the dimensionality of the data has to be sufficient
12:26 lizmat jnthn: that was my idea all along
12:26 jnthn So `my @a[2;2] = 1 xx *` should not wokr
12:26 lizmat indeed
12:26 jnthn OK, just checking :)
12:26 dogbert17 lizmat: RT #130024
12:26 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130024
12:27 dalek rakudo/nom: 469d1fc | lizmat++ | src/core/ShapedArray.pm:
12:27 dalek rakudo/nom: .STORE(item) on non1-dimmed array will always fail
12:27 dalek rakudo/nom:
12:27 dalek rakudo/nom: Since 1dimmed arrays already have their own .STORE(item), we can
12:27 dalek rakudo/nom: immediately throw here.
12:27 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/469d1fc533
12:27 dalek rakudo/nom: aedb8e7 | lizmat++ | src/core/Shaped1Array.pm:
12:27 dalek rakudo/nom: Make my @a[10] = ^Inf work
12:27 dalek rakudo/nom:
12:27 dalek rakudo/nom: Other dimensions coming up
12:27 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aedb8e7fd2
12:27 lizmat Make my @a[10] = ^Inf work
12:27 lizmat ah, cool
12:32 AlexDaniel joined #perl6-dev
12:41 cog_ joined #perl6-dev
12:47 MasterDuke jnthn: do you know where the --ll-exception backtrace printing happens in rakudo?
13:05 jnthn MasterDuke: iirc, it's handled inside of NQP
13:05 jnthn MasterDuke: --ll-exception suppresses calling the high level language's backtrace printer
13:06 jnthn src/HLL/Compiler.nqp:            if %adverbs<ll-exception> || !nqp::can(self, 'handle-exception') {
13:06 jnthn (found with git grep ll-exception)
13:07 MasterDuke hmm...will i be able to edit the linenumber/file info it has from rakudo?
13:09 jnthn ?
13:09 * jnthn doesn't understand the question
13:09 jnthn It gets its file/line info from the VM, which in turn come from its annotations
13:10 MasterDuke i rakudo, i can convert a m-CORE.setting linenumber to the actual source file and line number
13:10 MasterDuke *in
13:10 jnthn Where?
13:10 jnthn In backtrace printing?
13:10 MasterDuke anywhere
13:10 jnthn Yes, but where are you doing this?
13:10 jnthn I don't think you should fiddle with --ll-exception
13:10 jnthn The whole point of it is that it's not been massaged
13:10 MasterDuke but yeah, i want to change the backtrace printng
13:10 jnthn That's why it's useful
13:12 MasterDuke there have been a couple discussions, it's been pretty universal that people want the actual source file + linenumber
13:13 jnthn I want --ll-exception to continue to mean "whatever data comes directly from the annotations, without processing"
13:14 jnthn Are you doing it for Rakudo's high-level backtraces by keeping some kind of table of CORE.setting source lines and then mapping them while printing the backtrace?
13:14 MasterDuke yep
13:15 jnthn I guess that works. But please don't do it to --ll-exeption also.
13:15 jnthn Many times --ll-exception has been useful because it's simple.
13:16 jnthn I'm fine with the high level backtraces being mangled to print the CORE.setting source files
13:17 MasterDuke ok
13:17 jnthn (Many of the times --ll-exception is useful is when the code to print nice backtraces explodes in some way. Thus why keeping it as simple as possible is important.)
13:18 travis-ci joined #perl6-dev
13:18 travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make my @a[10] = ^Inf work
13:18 travis-ci https://travis-ci.org/rakudo/rakudo/builds/173487304 https://github.com/rakudo/rakudo/compare/aa97f86d9bf2...aedb8e7fd2be
13:18 travis-ci left #perl6-dev
13:18 MasterDuke what about an option on --ll-exception? e.g., --ll-exception[=use_the_source_luke]
13:18 buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
13:19 jnthn That just sounds like more complication.
13:19 lizmat fwiw, I would be fine with --ll-exception staying as it is
13:20 MasterDuke well, i'll leave it alone for now, if people end up wanting the source file info there it can be revisited
13:21 jnthn iirc, there's also an envvar you can set that gets Rakudo's backtrace printer to not omit any frames, which means if you want both "nothing trimmed" and "mapped CORE.setting line numbers" then there's a way to get them also
13:22 MasterDuke for testing purposes, anyone have a sample error that will produce m-CORE.setting line numbers without having to use --ll-exception?
13:23 MasterDuke ah, interesting
13:23 jnthn m: "abc".substr(1,2,3,4)
13:23 camelia rakudo-moar aedb8e: OUTPUT«Too many positionals passed; expected 2 or 3 arguments but got 5␤  in block <unit> at <tmp> line 1␤␤»
13:23 jnthn Grr
13:24 lizmat jnthn: ??
13:24 jnthn That error could do with containing one line from CORE.setting
13:24 jnthn Otherwise you can't see that it was the substr method that you called wrong
13:24 jnthn We trim things a bit too agressively sometimes...
13:25 MasterDuke yeah, that's why i'd then re-run with --ll-exception, and then have to open up m-CORE.setting to figure out what/where things were happening
13:26 MasterDuke but if that env variable does nearly the same thing as --ll-exception that might be easier
13:32 jnthn If normal users have to resort to --ll-exception then we should fix our defaults. :)
13:33 jnthn From a quick grep, seems RAKUDO_BACKTRACE_SETTING is the one I was thinking of
13:33 MasterDuke true, and this change i'm working on is arguably more useful for rakudo developers than for rakudo users
13:34 MasterDuke ah, adding that env variable that triggers the code i added in X::Comp.gist that i couldn't get to print earlier!
13:36 jnthn :)
13:36 MasterDuke btw, that is a normal workflow for me when i'm trying to fix a bug in rakudo (add --ll-exception, open m-CORE.setting, go to the line number, page up until i find the actual source file to edit to work on the bug)
13:41 MasterDuke hmm, but it doesn't print all the stuff i get with --ll-exception
13:41 MasterDuke m: say 1/0
13:41 camelia rakudo-moar aedb8e: OUTPUT«Attempt to divide 1 by zero using div␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»
13:42 MasterDuke adding RAKUDO_BACKTRACE_SETTING=1 before that locally triggers my code, but there's nothing to run the code on
13:43 MasterDuke adding --ll-exception spits out about 20 additional lines of backtrace, of which about 12 are from m-CORE.setting
14:00 raiph joined #perl6-dev
14:02 lizmat MasterDuke: my take on adding file/line number info: https://gist.github.com/lizmat/20c2c780b69e7af2b03ed86da3a55fea
14:03 lizmat needs tweaking of gen-cat.pl
14:03 lizmat SETTINGS.EXPORT sets $*SETTINGS-FILES/LINES for use in backtrace mapping
14:03 lizmat need to be afk now
14:03 lizmat so if you have questions, later  :-)  &
14:04 MasterDuke cool, i'll take a look
14:33 tony-o timotimo: i'm on osx, might have perf
14:58 tony-o nvm
15:00 dogbert17 is jnthn or MasterDuke17 lurking in the shadows?
15:01 MasterDuke good grief, if you think you need jnthn i doubt i can help!
15:02 dogbert17 it has to do with your bug RT #129781
15:02 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=129781
15:03 dogbert17 I ran jnthn's stress script with core dump turned on and got itto generate a core file, moght that be of help?
15:03 dogbert17 my spelling sucks
15:03 MasterDuke oooo, nice
15:04 dogbert17 it points to something called MVM_string_flatten (among others)
15:04 dogbert17 let me fix a gist ...
15:05 MasterDuke interesting. jnthn made some fixes to that recently, are you on moar HEAD?
15:05 dogbert17 yes
15:05 MasterDuke cool
15:06 jnthn There's still some more fixing needed for that, alas...
15:06 jnthn Though I got rid of the most immediate cause of it
15:07 dogbert17 here: https://gist.github.com/dogbert17/819c787aed1c1cf4679bb74407e53149
15:07 jnthn Yup, inside of hash
15:07 jnthn That's the place that still needs attention
15:09 dogbert17 maybe MaterDuke could add the contents of the gist to the RT if it is useful
15:12 MasterDuke added
15:12 dogbert17 cool
15:12 jnthn m: for ^100 { my $x = 'y' xx 10; (start { my %h = $x => 42 }) xx 4 }
15:12 camelia rakudo-moar aedb8e: OUTPUT«MoarVM panic: Memory allocation failed; could not allocate 4 bytes␤»
15:12 MasterDuke jnthn: if you don't mind multitasking back to the linenumber stuff. RAKUDO_BACKTRACE_SETTING and/or RAKUDO_VERBOSE_STACKFRAME don't do anything for me when using rakudo nom HEAD
15:13 jnthn ah, eval bot limits
15:13 [Tux] This is Rakudo version 2016.10-178-gaedb8e7 built on MoarVM version 2016.10-39-g4b9e3a8
15:13 [Tux] csv-ip5xs        3.169
15:13 [Tux] test            14.471
15:13 [Tux] test-t           6.760
15:13 [Tux] csv-parser      15.223
15:13 MasterDuke however, if i check against them to trigger my code, they do change the output
15:14 [Tux] $ grep ' 6.[0-7]' speed.log
15:14 [Tux] 2016-09-12 17:26:41 test-t 6.787
15:14 [Tux] 2016-09-15 13:10:01 test-t 6.796
15:14 [Tux] 2016-10-27 08:19:32 test-t 6.778
15:14 [Tux] 2016-11-02 09:41:22 test-t 6.781
15:14 [Tux] 2016-11-05 16:02:45 test-t 6.760
15:16 jnthn MasterDuke: Curious. I'd take a look in Backtrace.pm; it looks like it is used in the "nice" method, which in turn influences what is considered the next interesting index
15:18 jnthn It looks to me like it should be doing the right thing, but I having just tried it out it doesn't actually do what I'd expect
15:21 MasterDuke https://github.com/MasterDuke17/rakudo/tree/source_file_line_numbers has my rough draft at using original source file + line number
15:22 MasterDuke and yeah, for me they don't do anything at all for a normal rakudo
15:26 jnthn May be worth looking in to why
15:26 jnthn Gotta go cook some stuff now...but the code looks like it should be making a difference, so not clear why it doesn't.
15:27 MasterDuke yeah. i'm not finding Backtrace.pm terribly easy to follow, but i can see if i find anything
15:32 MasterDuke jnthn, lizmat, timotimo, FROGGS: if/when you get a chance, would you mind checking out my branch linked a couple lines above? it should give the original source file + line number when you run perl6 with RAKUDO_BACKTRACE_SETTING set
16:06 MasterDuke feedback from anyone else is also more than welcome, but i mentioned them because they had answered questions i had while doing it
17:02 seatek joined #perl6-dev
17:28 dalek rakudo/POSTBUILD_method: 9409d68 | timo++ | src/Perl6/Metamodel/BUILDPLAN.nqp:
17:28 dalek rakudo/POSTBUILD_method: POSTBUILD was bikeshod to TWEAK.
17:28 dalek rakudo/POSTBUILD_method: review: https://github.com/rakudo/rakudo/commit/9409d685b7
18:09 moritz .oO( bikeshot )
18:34 lizmat MasterDuke: re https://github.com/MasterDuke17/rakudo/commit/954110ec32d5fee18b9dd3559f0c659d740d79e8
18:34 lizmat the #line syntax is more generic than that (at least in Perl 5)
18:35 timotimo lizmat: since the code already only works if the source file is called "*CORE.setting", i don't think we need to emulate specifically what perl5 can handel :)
18:35 timotimo handle*
18:35 lizmat so I think you will need to catch the line number as well, and not just make this work for the moar CORE estting
18:35 lizmat *setting
18:35 timotimo oh, indeed, it also checks for m- in there
18:36 lizmat timotimo: true, but this is a really nice feature, that can be used to identify the inside of a string EVAL
18:37 lizmat if you have an EVAL string factory, it would be nice if you could add some identifying data to the code
18:37 lizmat $ perl -e '
18:37 lizmat > #line 5 foobar
18:37 lizmat > die'
18:37 lizmat Died at foobar line 5.
18:37 timotimo OK
20:01 lizmat good *, #perl6-dev
20:02 lizmat do we have a quick way of turning a list_i into a list_o ?
20:27 MasterDuke lizmat: should i go for the more general solution first, or are you fine with the core setting only start?
20:27 lizmat personally I would like to see a more general solution
20:27 lizmat not sure what jnthn's idea is about that
20:28 MasterDuke is there a spec for the general solution?
20:28 lizmat fwiw, I've always found the #line protocol in Perl 5 a very handy thing to have
20:33 dalek rakudo/nom: 692ec54 | lizmat++ | src/core/Rakudo/Internals.pm:
20:33 dalek rakudo/nom: Introduce R:I:ShapeIterator
20:33 dalek rakudo/nom:
20:33 dalek rakudo/nom: This is most of the logic of the previously anonymous class inside
20:33 dalek rakudo/nom: R:I:ShapeIndexIterator method abstracted, so that we can use it in
20:33 dalek rakudo/nom: other places as well.  Reform the ShapeIndexIterator to use this
20:33 dalek rakudo/nom: role in its anonymous class.  Performance degradation is minimal.
20:34 dalek rakudo/nom: This will allow us to use this logic much more easily for methods
20:34 dalek rakudo/nom: such as values, kv, pairs, antipairs, as well allow use to more
20:34 dalek rakudo/nom: easily create custom versions of these for 2/3dimmed arrays.
20:34 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/692ec544aa
20:35 dalek nqp: 4bbea66 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (3 files):
20:35 dalek nqp: [js] Reduce the amount of failed lookups in the per STable prototypes in preparation for installing a Proxy.
20:35 dalek nqp: review: https://github.com/perl6/nqp/commit/4bbea66bb2
20:35 dalek nqp: c5079bd | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
20:35 dalek nqp: [js] Fix bugs after null -> Null changes.
20:35 dalek nqp: review: https://github.com/perl6/nqp/commit/c5079bd8fa
21:00 dalek rakudo/nom: 02ea7cd | lizmat++ | src/core/Shaped1Array.pm:
21:00 dalek rakudo/nom: Restore 1dimmed.keys optimized version
21:00 dalek rakudo/nom:
21:00 dalek rakudo/nom: The generic .keys doesn't handle 1dimmed differently anymore
21:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/02ea7cdf91
21:21 dalek rakudo/nom: c963efd | lizmat++ | src/core/ (3 files):
21:21 dalek rakudo/nom: .reverse/rotate always illegal on all shaped arrays
21:21 dalek rakudo/nom:
21:21 dalek rakudo/nom: Both native and non-native.  Except when overridden for the 1dimmed
21:21 dalek rakudo/nom: case.  So move this to the ShapedArrayCommon role.
21:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c963efdd2c
21:21 travis-ci joined #perl6-dev
21:21 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Introduce R:I:ShapeIterator
21:22 travis-ci https://travis-ci.org/rakudo/rakudo/builds/173558996 https://github.com/rakudo/rakudo/compare/aedb8e7fd2be...692ec544aaae
21:22 travis-ci left #perl6-dev
21:22 buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
21:53 travis-ci joined #perl6-dev
21:53 travis-ci Rakudo build passed. Elizabeth Mattijsen 'Restore 1dimmed.keys optimized version
21:53 travis-ci https://travis-ci.org/rakudo/rakudo/builds/173562847 https://github.com/rakudo/rakudo/compare/692ec544aaae...02ea7cdf911c
21:53 travis-ci left #perl6-dev
22:09 [Coke] jnthn: what does "worreva" mean? "whatever" ?
22:13 dalek nqp: b890b10 | coke++ | src/ (9 files):
22:13 dalek nqp: fix spelling
22:13 dalek nqp: review: https://github.com/perl6/nqp/commit/b890b109f6
22:26 lizmat good night, #perl6-dev!
22:26 [Coke] ~~
22:30 travis-ci joined #perl6-dev
22:30 travis-ci Rakudo build passed. Elizabeth Mattijsen '.reverse/rotate always illegal on all shaped arrays
22:30 travis-ci https://travis-ci.org/rakudo/rakudo/builds/173565697 https://github.com/rakudo/rakudo/compare/02ea7cdf911c...c963efdd2c2c
22:30 travis-ci left #perl6-dev
23:08 stmuk_ joined #perl6-dev
23:45 jnthn [Coke]: Yes. :)

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