dalek kudo/POSTBUILD_method: fdc90a2 | timotimo++ | src/Perl6/Metamodel/BUILDPLAN.nqp:
enable POSTBUILD to take part in object construction

it will be called after everything else has been done. it'll get the same arguments as the BUILD submethod, but things have already been initialized, default values populated, ...		 00:13
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
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?
if so, try and see what "for nqp::hllize($the-nqparray-in-question) { ... }" will do 00:17
if that makes it work, it could be enough to generate an QAST::Op( :op<hllize>, ... ) around the code you generate
MasterDuke_ thanks, i'll try that next 00:18
timotimo good luck. i'm off to bed very soon
MasterDuke_ later... 00:19
ah ha! success with binding and a while on an nqp::iterator! 00:22
timotimo++ 00:23
lizmat Files=1151, Tests=53712, 216 wallclock secs (12.91 usr 3.64 sys + 1308.15 cusr 122.34 csys = 1447.04 CPU) 08:19
FROGGS o/ 09:38
lizmat FROGGS \o 09:46
dalek kudo/nom: aa97f86 | lizmat++ | src/core/ (3 files):
Introduce R:I:ShapeIndexIterator

  - a 5x faster way to generate indices for multi-dim arrays
  - let @a[2;2].keys use that
  - falls back to IntRangeIterator for single dimmed arrays
  - ignore shape if 1 dimmed and *, makes my @a[*] work, partly fixes RT #124502
  - makes methods like .values, .kv, .pairs about 30% faster as well		 10:16
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124502
ast: cf300e4 | lizmat++ | S02-types/array-shapes.t:
Unfudge now passing test
 10:20
lizmat jnthn: hope it's ok to make my @a[*] work, or do you consider this to be 6.d material ? 10:21
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
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
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␤␤»
lizmat m: my @a[10] = 42 xx *; dd @a # as this ?
camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤ in block <unit> at <tmp> line 1␤␤»
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:42
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␤»
lizmat dogbert17: I'm primarily focused on making things faster 11:47
do you have a ticket number for that ?
dogbert17 lizmat: I know, but it was worth a shot
dunno if there's a ticket number to be honest, tries too look ... 11:48
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
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
I'll fix the RT
lizmat dogbert17: any idea how much faster ? 11:53
lizmat likes independent benchmarks
dogbert17 real 6m17.384 user 6m16.172s with Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-13-g34c375a 11:54
I see that you have some supernew fixes, maybe I should rebuild and run again first 11:55
jnthn lizmat: Don't think making `my @a[*]` work is a problem...it's the test suite that defines the language, anyway. :) 11:56
dogbert17 give me a few mins, in the meantime gist.github.com/dogbert17/3069f8d8...232d32d433 11:57
lizmat jnthn: ok 12:01
jnthn: opinions on my @a[10] = 42 xx * ?
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
m: my @a[10] = 42 xx 10
camelia ( no output )
jnthn m: my @a[10] = 42 xx *
camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: my @a[10] = 42 xx 9 12:03
camelia ( no output )
jnthn m: my @a[10] = 42 xx 11
camelia rakudo-moar aa97f8: OUTPUT«Index 10 for dimension 1 out of range (must be 0..9)␤ in block <unit> at <tmp> line 1␤␤»
jnthn Arguably we could decide not to whine based on is-lazy
Depends whether we see the convenience coming out ahead of "you asked me to complain if you constraints are broken" 12:04
lizmat well, the use-case I see where the size of the shaped array is disconnected from its initialization 12:06
my @a[$size] = 0 xx *
of course, in this case you could have said 0 xx $size, I know 12:07
but that was not the point :-)
jnthn Well yes, the question is when there is a point :-) 12:08
(How often is initialization separated?)
m: my @a[10] Z= 0 xx * 12:09
camelia ( no output )
jnthn Also you can always do that
m: my @a[3;3] Z= 1 xx *; say @a
camelia rakudo-moar aa97f8: OUTPUT«[[1 1 1] [1 1 1] [1 1 1]]␤»
lizmat well, as a data point: spectest passes if we don't die on a lazy iterator
jnthn Which even works without you knowing the number of dimensions :)
Yes, I'd only have encoded dying on that in the spectest if I'd expected us to always do so :) 12:10
lizmat fwiw, the performance burden on this would be minimal 12:11
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
lizmat *is-lazy
jnthn Entirely about catching mistakes.
lizmat if the iterator is not lazy, it would die 12:13
$ 6 'my @a[10] = ^Inf; dd @a'
Array.new(:shape(10,), [0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
$ 6 'my @a[10] = ^11; dd @a'
Index 10 for dimension 1 out of range (must be 0..9)
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
jnthn Right, that's the question. Is laziness a good enough hint that we don't mind silently discarding data.
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]␤»
jnthn *nod* 12:16
Yeah, there is precedent.
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:17
my @a[2;2] = (1 xx *) xx *; # does this case work also? 12:18
lizmat i think it should 12:21
even ($++ xx *) xx * :-) 12:22
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
I think we can enforce that the dimensionality of the data has to be sufficient
lizmat jnthn: that was my idea all along 12:26
jnthn So `my @a[2;2] = 1 xx *` should not wokr
lizmat indeed
jnthn OK, just checking :)
dogbert17 lizmat: RT #130024
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130024
dalek kudo/nom: 469d1fc | lizmat++ | src/core/ShapedArray.pm:
.STORE(item) on non1-dimmed array will always fail

Since 1dimmed arrays already have their own .STORE(item), we can immediately throw here.		 12:27
kudo/nom: aedb8e7 | lizmat++ | src/core/Shaped1Array.pm:
Make my @a[10] = ^Inf work

Other dimensions coming up
lizmat Make my @a[10] = ^Inf work
ah, cool
MasterDuke jnthn: do you know where the --ll-exception backtrace printing happens in rakudo? 12:47
jnthn MasterDuke: iirc, it's handled inside of NQP 13:05
MasterDuke: --ll-exception suppresses calling the high level language's backtrace printer
src/HLL/Compiler.nqp: if %adverbs<ll-exception> || !nqp::can(self, 'handle-exception') { 13:06
(found with git grep ll-exception)
MasterDuke hmm...will i be able to edit the linenumber/file info it has from rakudo? 13:07
jnthn ? 13:09
jnthn doesn't understand the question
It gets its file/line info from the VM, which in turn come from its annotations
MasterDuke i rakudo, i can convert a m-CORE.setting linenumber to the actual source file and line number 13:10
*in
jnthn Where?
In backtrace printing?
MasterDuke anywhere
jnthn Yes, but where are you doing this?
I don't think you should fiddle with --ll-exception
The whole point of it is that it's not been massaged
MasterDuke but yeah, i want to change the backtrace printng
jnthn That's why it's useful
MasterDuke there have been a couple discussions, it's been pretty universal that people want the actual source file + linenumber 13:12
jnthn I want --ll-exception to continue to mean "whatever data comes directly from the annotations, without processing" 13:13
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
jnthn I guess that works. But please don't do it to --ll-exeption also. 13:15
Many times --ll-exception has been useful because it's simple.
I'm fine with the high level backtraces being mangled to print the CORE.setting source files 13:16
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.)
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make my @a[10] = ^Inf work 13:18
travis-ci.org/rakudo/rakudo/builds/173487304 github.com/rakudo/rakudo/compare/a...db8e7fd2be
MasterDuke what about an option on --ll-exception? e.g., --ll-exception[=use_the_source_luke]
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
jnthn That just sounds like more complication. 13:19
lizmat fwiw, I would be fine with --ll-exception staying as it is
MasterDuke well, i'll leave it alone for now, if people end up wanting the source file info there it can be revisited 13:20
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:21
MasterDuke for testing purposes, anyone have a sample error that will produce m-CORE.setting line numbers without having to use --ll-exception? 13:22
ah, interesting 13:23
jnthn m: "abc".substr(1,2,3,4)
camelia rakudo-moar aedb8e: OUTPUT«Too many positionals passed; expected 2 or 3 arguments but got 5␤ in block <unit> at <tmp> line 1␤␤»
jnthn Grr
lizmat jnthn: ?? 13:24
jnthn That error could do with containing one line from CORE.setting
Otherwise you can't see that it was the substr method that you called wrong
We trim things a bit too agressively sometimes...
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:25
but if that env variable does nearly the same thing as --ll-exception that might be easier 13:26
jnthn If normal users have to resort to --ll-exception then we should fix our defaults. :) 13:32
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
ah, adding that env variable that triggers the code i added in X::Comp.gist that i couldn't get to print earlier! 13:34
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)
hmm, but it doesn't print all the stuff i get with --ll-exception 13:41
m: say 1/0
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␤␤»
MasterDuke adding RAKUDO_BACKTRACE_SETTING=1 before that locally triggers my code, but there's nothing to run the code on 13:42
adding --ll-exception spits out about 20 additional lines of backtrace, of which about 12 are from m-CORE.setting 13:43
lizmat MasterDuke: my take on adding file/line number info: gist.github.com/lizmat/20c2c780b69...6da3a55fea 14:02
needs tweaking of gen-cat.pl 14:03
SETTINGS.EXPORT sets $*SETTINGS-FILES/LINES for use in backtrace mapping
need to be afk now
so if you have questions, later :-) &
MasterDuke cool, i'll take a look 14:04
tony-o timotimo: i'm on osx, might have perf 14:33
nvm 14:58
dogbert17 is jnthn or MasterDuke17 lurking in the shadows? 15:00
MasterDuke good grief, if you think you need jnthn i doubt i can help! 15:01
dogbert17 it has to do with your bug RT #129781 15:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129781
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
my spelling sucks
MasterDuke oooo, nice
dogbert17 it points to something called MVM_string_flatten (among others) 15:04
let me fix a gist ...
MasterDuke interesting. jnthn made some fixes to that recently, are you on moar HEAD? 15:05
dogbert17 yes
MasterDuke cool
jnthn There's still some more fixing needed for that, alas... 15:06
Though I got rid of the most immediate cause of it
dogbert17 here: gist.github.com/dogbert17/819c787a...4407e53149 15:07
jnthn Yup, inside of hash
That's the place that still needs attention
dogbert17 maybe MaterDuke could add the contents of the gist to the RT if it is useful 15:09
MasterDuke added 15:12
dogbert17 cool
jnthn m: for ^100 { my $x = 'y' xx 10; (start { my %h = $x => 42 }) xx 4 }
camelia rakudo-moar aedb8e: OUTPUT«MoarVM panic: Memory allocation failed; could not allocate 4 bytes␤»
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
jnthn ah, eval bot limits 15:13
[Tux] This is Rakudo version 2016.10-178-gaedb8e7 built on MoarVM version 2016.10-39-g4b9e3a8
csv-ip5xs 3.169
test 14.471
test-t 6.760
csv-parser 15.223
MasterDuke however, if i check against them to trigger my code, they do change the output
[Tux] $ grep ' 6.[0-7]' speed.log 15:14
2016-09-12 17:26:41 test-t 6.787
2016-09-15 13:10:01 test-t 6.796
2016-10-27 08:19:32 test-t 6.778
2016-11-02 09:41:22 test-t 6.781
2016-11-05 16:02:45 test-t 6.760
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:16
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:18
MasterDuke github.com/MasterDuke17/rakudo/tre...ne_numbers has my rough draft at using original source file + line number 15:21
and yeah, for me they don't do anything at all for a normal rakudo 15:22
jnthn May be worth looking in to why 15:26
Gotta go cook some stuff now...but the code looks like it should be making a difference, so not clear why it doesn't.
MasterDuke yeah. i'm not finding Backtrace.pm terribly easy to follow, but i can see if i find anything 15:27
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 15:32
feedback from anyone else is also more than welcome, but i mentioned them because they had answered questions i had while doing it 16:06
dalek kudo/POSTBUILD_method: 9409d68 | timo++ | src/Perl6/Metamodel/BUILDPLAN.nqp:
POSTBUILD was bikeshod to TWEAK.
 17:28
moritz
.oO( bikeshot )
 18:09
lizmat MasterDuke: re github.com/MasterDuke17/rakudo/com...9d740d79e8 18:34
the #line syntax is more generic than that (at least in Perl 5)
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
handle*
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
*setting
timotimo oh, indeed, it also checks for m- in there
lizmat timotimo: true, but this is a really nice feature, that can be used to identify the inside of a string EVAL 18:36
if you have an EVAL string factory, it would be nice if you could add some identifying data to the code 18:37
$ perl -e '
> #line 5 foobar
> die'
Died at foobar line 5.
timotimo OK
lizmat good *, #perl6-dev 20:01
do we have a quick way of turning a list_i into a list_o ? 20:02
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
not sure what jnthn's idea is about that
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
dalek kudo/nom: 692ec54 | lizmat++ | src/core/Rakudo/Internals.pm:
Introduce R:I:ShapeIterator

This is most of the logic of the previously anonymous class inside R:I:ShapeIndexIterator method abstracted, so that we can use it in other places as well. Reform the ShapeIndexIterator to use this role in its anonymous class. Performance degradation is minimal. This will allow us to use this logic much more easily for methods such as values, kv, pairs, antipairs, as well allow use to more easily create custom versions of these for 2/3dimmed arrays.		 20:33
p: 4bbea66 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (3 files):
[js] Reduce the amount of failed lookups in the per STable prototypes in preparation for installing a Proxy.
 20:35
p: c5079bd | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] Fix bugs after null -> Null changes.
kudo/nom: 02ea7cd | lizmat++ | src/core/Shaped1Array.pm:
Restore 1dimmed.keys optimized version

The generic .keys doesn't handle 1dimmed differently anymore		 21:00
kudo/nom: c963efd | lizmat++ | src/core/ (3 files):
.reverse/rotate always illegal on all shaped arrays

Both native and non-native. Except when overridden for the 1dimmed case. So move this to the ShapedArrayCommon role.		 21:21
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Introduce R:I:ShapeIterator
travis-ci.org/rakudo/rakudo/builds/173558996 github.com/rakudo/rakudo/compare/a...2ec544aaae 21:22
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Restore 1dimmed.keys optimized version 21:53
travis-ci.org/rakudo/rakudo/builds/173562847 github.com/rakudo/rakudo/compare/6...ea7cdf911c
[Coke] jnthn: what does "worreva" mean? "whatever" ? 22:09
dalek p: b890b10 | coke++ | src/ (9 files):
fix spelling
 22:13
lizmat good night, #perl6-dev! 22:26
[Coke] ~~
travis-ci Rakudo build passed. Elizabeth Mattijsen '.reverse/rotate always illegal on all shaped arrays 22:30
travis-ci.org/rakudo/rakudo/builds/173565697 github.com/rakudo/rakudo/compare/0...63efdd2c2c
jnthn [Coke]: Yes. :) 23:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!