MasterDuke jnthn: did you see lizmat's comments about my branch? think i should i try for a more general implementation of #line? 00:35
the Grammar change is relatively straightforward, but i'm not quite sure how to know when to edit the backtrace 00:36
[Tux] This is Rakudo version 2016.10-181-gc963efd built on MoarVM version 2016.10-39-g4b9e3a8 08:39
csv-ip5xs 3.381
test 15.252
test-t 7.096
csv-parser 15.497
gfldex m: my Str $s = Str; $s.contains("anything at all"); 10:49
camelia rakudo-moar c963ef: OUTPUT«Cannot resolve caller contains(Str: Str); none of these signatures match:␤ (Cool:D $: Cool $needle, Cool $pos = 0, *%_)␤ (Str:D $: Str:D $needle, *%_)␤ (Str:D $: Str:D $needle, Int:D $pos, *%_)␤ in block <unit> at <tmp> line 1␤␤»
gfldex is that intentional?
m: my Str $s = Str; $s.match(/a/); 11:09
camelia rakudo-moar c963ef: OUTPUT«Use of uninitialized value of type Str in string context.␤Methods .^name, .perl, .gist, or .say can be used to stringify it to something meaningful.␤ in block <unit> at <tmp> line 1␤»
gfldex i would expect .match and .contains to behave the same way when invoced on a type object 11:10
lizmat Files=1151, Tests=53712, 213 wallclock secs (12.71 usr 3.77 sys + 1299.50 cusr 121.50 csys = 1437.48 CPU) 12:04
dalek kudo/nom: 8b40d1b | lizmat++ | src/core/Rakudo/Internals.pm:
Make the ShapeIterator role more usable

A class implementing this role only needs to supply a !init-list and a !result method. This should help implementing other iterators, like for .values and friends.		 12:57
lizmat m: role A { has $!foo }; class B does A { method b() { $!foo := 42 } }; B.b # shouldn't this just work ? 13:31
camelia rakudo-moar 8b40d1: OUTPUT«X::TypeCheck::Binding exception produced no message␤ in method b at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
lizmat jnthn ^^^
timotimo m: class B does A { has $!foo; method b() { $!foo := 42 } }; B.b
camelia rakudo-moar 8b40d1: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Invalid typename 'A'␤at <tmp>:1␤------> class B does A⏏ { has $!foo; method b() { $!foo := 42 }␤»
timotimo m: class B { has $!foo; method b() { $!foo := 42 } }; B.b 13:32
camelia rakudo-moar 8b40d1: OUTPUT«Cannot bind attributes in a type object␤ in method b at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
timotimo m: class B does A { has $!foo; method b() { $!foo := 42 } }; B.new.b
camelia rakudo-moar 8b40d1: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Invalid typename 'A'␤at <tmp>:1␤------> class B does A⏏ { has $!foo; method b() { $!foo := 42 }␤»
timotimo grmbl
role A { has $!foo }; class B does A { method b() { $!foo := 42 } }; B.new.b
m: role A { has $!foo }; class B does A { method b() { $!foo := 42 } }; B.new.b
camelia rakudo-moar 8b40d1: OUTPUT«X::TypeCheck::Binding exception produced no message␤ in method b at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
timotimo m: role A { has $!foo }; class B does A { method b() { $!foo = 42 } }; B.new.b
camelia ( no output )
lizmat yeah, I missed the .new in my example, but the result is the same, no? 13:33
binding just doesn't work
timotimo right
are assignments to native attributes already just nqp::bindattr? 13:34
er, not "native"
but that kind of makes it awkward to put Scalar objects into attributes and assigning binds the new value to replace the scalar instead of assigning into the scalar? 13:35
except if you use accessors, you potentially get an AttrRef that's scalar-like? perhaps?
lizmat what I want to achieve is to bind an nqp::list from a '$!reified' slot
if I just assign, I get this: 13:36
$ 6l 'my @a[10] = ^10; say @a.iterator.pull-one'
Segmentation fault: 11
:-(
ok, I guess I'll work around it :-(
timotimo: do you agree this is buggable ? 13:37
timotimo huh, ouch 13:38
nine lizmat: all segfaults are buggable
timotimo quite
nine Well except self inflicted NativeCall trickery of course :)
lizmat RT #130030 13:45
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130030
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make the ShapeIterator role more usable 13:46
travis-ci.org/rakudo/rakudo/builds/173660042 github.com/rakudo/rakudo/compare/c...40d1b14de0
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
tbrowder hi #perl6-dev 13:53
question of the day ref arrays (containers): is returning a generated container from a sub expensive as compared to filling an input container with the generated data?
dalek kudo/nom: 7ff1f13 | lizmat++ | src/core/Rakudo/Internals.pm:
Make R:I:ShapeIterator *always* take a list

To get around RT #130030
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130030
nine tbrowder: when in doubt, benchmark :) 13:56
tbrowder: also when you're totally sure, still benchmark!
tbrowder i understand, but i am more concerned with how it's done, i.e., is there an efficient return of a container such that there is no extra copying. i'm trying to decide, in general (not time, but space), which would be better. 14:00
timotimo containers are just objects. objects are returned just by returning the pointer 14:08
there is no difference between returning an Int vs returning an Array 14:09
tbrowder okay! many thanks, timotimo! 14:10
timotimo sure
dalek kudo/nom: 736ab11 | lizmat++ | src/core/ (3 files):
Re-imagine .iterator and .values on shaped arrays

Now uses the ShapeIterator role. Makes it more than 4x as fast. Also fix ShapeIterator.pull-one: it needs to be raw to allow .values to return left-values		 14:20
lizmat afk&
stmuk_ nine: any suggestions about rt.perl.org/Ticket/Display.html?id=130031 14:26
nine stmuk_: does C:\rakudo\share\perl6\ exist? 14:46
stmuk_: is the error message always about the 'resources' directory or is it sometimes something else like 'sources' or 'short'? 14:48
stmuk_ nine: the full directory path it complains about exists after the build terminates (but not before) 14:49
its always the same error
nine So C:\rakudo\share\perl6\resources does exist afterwards? 14:50
stmuk_ yes 14:51
nine On what file system does this happen? 14:53
stmuk_ NTFS I guess 14:54
nine The whole thing is extremely odd as exactly the same code seems to be able to create e.g. the sources directory just fine
stmuk_ irclog.perlgeek.de/perl6/2016-07-04#i_12783998 14:55
not sure if its relevant (since the release at the end of that month was ok)
hmm I can try .08 and .09 14:56
nine So far I've got absolutely no idea at all
You could try switching the my $resources-dir = self!resources-dir; and my $dist-dir = self!dist-dir; lines in src/core/CompUnit/Repository/Installation.pm (lines 173 and 174) to see if the error changes. 14:58
stmuk_ ok
nine That may give us a hint if this is about 'resources' somehow or just some confusion left by the previous statements
stmuk_ exactly the same error & dir created 15:18
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Re-imagine .iterator and .values on shaped arrays
travis-ci.org/rakudo/rakudo/builds/173671383 github.com/rakudo/rakudo/compare/7...6ab11d9812
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. 15:19
nine So it really is about the resources directory? WTF?
stmuk_ damm windows 15:20
nine Any anti virus involved? 15:22
stmuk_ nope
I've reproduced on two virtualbox VMs 15:23
nine Then I fear, only a bisect can give us another hint 15:24
stmuk_ yeah I'm trying that
nine: I can't reproduce the problem with nom anyway 17:30
dalek kudo/nom: 9a6379d | lizmat++ | src/core/Rakudo/Internals.pm:
Abstract indices logic into a private method

So we can also use it for .kv, pairs and antipairs		 17:32
nine stmuk_: oh, then we're either lucky or we have one of those lovely heisenbugs on our hands 17:33
stmuk_ my glass is half empty :) 17:34
mst optimist: glass is half full 17:36
pessimist: glass is half empty 17:37
D&D player: I down the glass. what happens?
dalek kudo/nom: e42b68e | lizmat++ | src/core/ (3 files):
Make .kv on shaped Arrays about 4x faster

Using the new ShapeIterator logic. Native shaped arrays for now uses the old logic.		 18:08
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Abstract indices logic into a private method 18:28
travis-ci.org/rakudo/rakudo/builds/173704903 github.com/rakudo/rakudo/compare/7...6379d50ccb
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: 0f2566a | lizmat++ | src/core/ (3 files):
Make .pairs on shaped Arrays about 2.8x faster

Using the new ShapeIterator logic. .kv on native shaped arrays for now uses the old logic.		 18:31
kudo/nom: f608a33 | lizmat++ | src/core/ (3 files):
Make .antipairs on shaped Arrays about 2.8x faster

Using the new ShapeIterator logic. .antipairs on native shaped arrays for now uses the old logic.		 18:45
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make .kv on shaped Arrays about 4x faster 18:59
travis-ci.org/rakudo/rakudo/builds/173711312 github.com/rakudo/rakudo/compare/9...2b68e00291
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. 19:00
dalek kudo/nom: 7a2baf4 | lizmat++ | src/core/List.pm:
Make List.kv about 30% faster

Using the same trick developed for .kv on shaped arrays		 19:05
japhb
.oO( lizmat has created the "one weird trick" ... )
 19:21
masak japhb: ...that the doctors don't want you to know about? :P 19:28
DrForr . o ( who? ) 19:30
lizmat
.oO( remove trick from vocabulary )
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make .pairs on shaped Arrays about 2.8x faster 19:38
travis-ci.org/rakudo/rakudo/builds/173715326 github.com/rakudo/rakudo/compare/e...2566a99a09
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
dalek kudo/nom: 03c6212 | lizmat++ | src/core/ (2 files):
Introduce R:I:IterateKeyValueFromIterator

Logic abstracted away from List.kv, so we can use it elsewhere, specifically on 1dimmmed shaped arrays.		 19:55
kudo/nom: ed36e60 | lizmat++ | src/core/Shaped1Array.pm:
Give 1dimmed arrays its own iterator

Makes for loops with these about 3x faster, as well as .values
lizmat
.oO( this channel is getting pretty boring )
mst maybe everybody's too busy understanding all the cool stuff you keep doing to do anything else :D 19:56
lizmat hopes so :-) 19:59
japhb We're all making way for the person Getting Things Done. :-) 20:09
timotimo mst: did you see how POSTBUILD was renamed to TWEAK?
mst timotimo: nope
moritz that's not yet in nom, right?
timotimo well, it was. and i'm hoping for some testing and praise
it is not
mst didn't sleep friday night due to really early flight
timotimo oh :( 20:10
dalek kudo/nom: 608de26 | lizmat++ | src/core/Shaped1Array.pm:
Give 1dimmed arrays its own .kv

Makes it 7x faster
mst so have basically spent the weekend going 'bleh'
moritz timotimo: what's the branch name?
ah, POSTBUILD_method 20:12
japhb Having just read another Squirrel Girl collection this morning, I'm imagining all branches named in Squirrel: "chit-chiktuk-cht" 20:13
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make .antipairs on shaped Arrays about 2.8x faster 20:14
travis-ci.org/rakudo/rakudo/builds/173717626 github.com/rakudo/rakudo/compare/0...08a3380918
jnthn timotimo: Just glanced the POSTBUILD_method branch and the code changes look sensible enough, at least :) 20:40
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make List.kv about 30% faster 20:45
travis-ci.org/rakudo/rakudo/builds/173721157 github.com/rakudo/rakudo/compare/f...2baf46f401
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: e829aa1 | lizmat++ | src/core/ (2 files):
Introduce R:I:IteratePairFromIterator

Abstract logic from List.pairs, so that we can use it for 1dimmed shaped arrays also.		 20:47
MasterDuke jnthn: speaking of branches... and if you don't mind me bothering you again (and again...). do you have an opinion on my linenumber branch? 20:54
because i know the whole world is interested... github.com/MasterDuke17/rakudo/tre...ne_numbers 20:56
dalek kudo/nom: b7d9537 | lizmat++ | src/core/Shaped1Array.pm:
Give 1dimmed shaped arrays its own .pairs

Makes it about 3x as fast		 20:58
jnthn MasterDuke: Not quite sure why `if %*ENV<RAKUDO_BACKTRACE_SETTING> and ...` needs to look at %*ENV<RAKUDO_BACKTRACE_SETTING>? 21:02
I mean, we've already done filtering by this point... 21:03
It's a bit hack with the @?SOURCE_LINE_NUMBERS thingy
MasterDuke pretty sure if i don't do that it prints the longer stacktrace all the time
jnthn I think it's OK for now if people want it 21:04
MasterDuke yeah, i started with a hash, but missing serialization...
jnthn I mean the whole approach of post-processing is a bit of a hack.
MasterDuke ha, that too
jnthn Was there a reason not to arrange for us to emit mapped annotations as part of code-gen? 21:05
MasterDuke other than i don't know how to do that? dunno 21:06
where would that happen?
lizmat would prefer mapped annotations :-)
MasterDuke jnthn: actually, i thought you didn't want to mess with those? 21:07
timotimo i'm not sure how to signal different filenames to the Stmts (or whoever needs it) nodes
jnthn No, I didn't want any clever post-processing on the --ll-exception code path 21:08
timotimo because things could already be broken at this point 21:09
and --ll-exception ought to be as stable as possible
jnthn Right
But if it's just pulling out file/line info from the VM's mappings that are already with the mapped line/file there's no risk there
I think that if you kept a mapping of file/line overrides when compiling, then we just go on attaching $/ to .node(...) 21:10
MasterDuke that's where i tried to start, but wasn't able to figure out what exactly was going on and/or how to change it
jnthn And then it's .lineof in HLL::Compiler that would handle the mapping
MasterDuke (changing the original mapping that is) 21:11
jnthn iirc, MAST::Annotated takes a file/line
MasterDuke so then switched to the current strategy
jnthn: just checked, without that "if %*ENV<RAKUDO_BACKTRACE_SETTING> and ..." the long backtrace gets printed 21:13
m: say 1/0
camelia rakudo-moar b7d953: 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 locally i get the long backtrace 21:14
dalek kudo/nom: c5c6001 | lizmat++ | src/core/ (2 files):
Introduce R:I:IterateAntiPairFromIterator

Basically IteratePairFromIterator but with key/value reversed. Make sure List.antipairs uses that, which makes it almost 2x faster.
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Give 1dimmed arrays its own iterator 21:19
travis-ci.org/rakudo/rakudo/builds/173729787 github.com/rakudo/rakudo/compare/7...36e605edf7
jnthn MasterDuke: Odd, wonder why...
MasterDuke jnthn: something definitely seems off with RAKUDO_BACKTRACE_SETTING and RAKUDO_VERBOSE_STACKFRAME 21:20
japhb lizmat: At the current point, what's the fastest way to implement a 2D grid that has to be able to hold objects of various types? Right now I'm just using a regular Array, and instantiating it with defaults using: my @grid = [ [ $default xx $columns ] xx $rows ]; 21:21
MasterDuke m: %*ENV<RAKUDO_BACKTRACE_SETTING> = 1; say 1/0 21:22
camelia rakudo-moar b7d953: 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 bisect: %*ENV<RAKUDO_BACKTRACE_SETTING> = 1; say 1/0
bisectable6 MasterDuke, On both starting points (old=2015.12 new=c5c6001) the exit code is 1 and the output is identical as well
MasterDuke, Output on both points: Attempt to divide 1 by zero using div␤ in block <unit> at /tmp/BxnEvLUc53 line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/BxnEvLUc53 line 1␤
lizmat japhb: well, in that example, you would really want "is default" to work
MasterDuke bisect: %*ENV<RAKUDO_VERBOSE_STACKFRAME> = 2; say 1/0
bisectable6 MasterDuke, On both starting points (old=2015.12 new=c5c6001) the exit code is 1 and the output is identical as well
MasterDuke, gist.github.com/6750ac3d98a9ddb9f9...8ae8f232f0
lizmat but generally, that would be the way to do it
japhb: but .STORE is still on my list to optimize for >1 dimmes 21:23
*dimmed
japhb dimmed? 21:26
MasterDuke jnthn: my guess is it's some check later on for filename.ends-with(".setting") that takes a differen path since my code changes the filename 21:27
dalek kudo/nom: 1c425f9 | lizmat++ | src/core/Shaped1Array.pm:
Give 1dimmed arrays its own .antipairs

Making it more than 3x as fast.		 21:28
lizmat japhb: 1dimmed 2dimmed 3dimmed Ndimmed :-) 21:29
MasterDuke: why are you checking the filename at all ?
japhb lizmat: Ah!
jnthn MasterDuke: Ohh...yes, that's quite likely
MasterDuke: fwiw, github.com/perl6/nqp/blob/master/s...r.nqp#L664 is a place I'd start looking with regard to writing out correct annotations in the first place 21:31
MasterDuke lizmat: because i wasn't sure how widely applicable my code would be, wanted to keep effects as minimal as possible at first
lizmat MasterDuke: I would like to see it everywhere, as it is also a very nice way to annotate string EVAL's 21:32
pmurias MasterDuke: I override serialize_sc when cross compiling 21:33
MasterDuke and the way @?SOURCE_LINE_NUMBERS is currently implemented, it only works for one source file at a time
lizmat $ perl -e '
#line 5 foo
die'
Died at foo line 5.
example from Perl 5
MasterDuke pmurias: yeah, the first file it looked at in the JS backed looked like the same simple edit could be made, but i think there's another file that complicates things 21:34
jnthn pmurias: Yes, I mentioned you in a comment on that PR :)
lizmat BTW, iterating a 1dimmed shaped array is now faster than iterating a unshaped array:
m: my @a[1000] = ^1000; my $now = now; for ^1000 { for @a { } }; say now - $now 21:35
camelia rakudo-moar c5c600: OUTPUT«0.45553289␤»
MasterDuke that PR is likely not spectacular
lizmat m: my @a = ^1000; my $now = now; for ^1000 { for @a { } }; say now - $now
camelia rakudo-moar c5c600: OUTPUT«0.609908␤»
jnthn lizmat: Nice! :)
lizmat++
jnthn wanders back to Distraction Of The Day (the Switzerland/Indian TTR expansion pack :)) 21:36
japhb That's so cool lizmat! 21:37
lizmat fwiw, it turns out it doesn't make sense to create special 2/3dim versions of .kv,.values,.pairs,antipairs 21:38
since the generic ShapeIterator has all of the index logic already in there, and can quickly pass its indices to atposnd 21:39
as opposed to using atpos2d(..., atpos_i($!indices,0), atpos_i($!indices,1)) 21:40
moritz timotimo: fwiw I've done a small bit of testing with TWEAK, and so far, it seems to work perfectly
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Give 1dimmed arrays its own .kv 21:52
travis-ci.org/rakudo/rakudo/builds/173733058 github.com/rakudo/rakudo/compare/e...8de26e30e3
MasterDuke lizmat: i'm going to look into working directly with the annotations, and i'll keep the general use case in mind 21:59
lizmat MasterDuke++ :-)
timotimo moritz: that's much more testing than i did! :) 22:23
moritz: want to write some spec tests? ;)
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Introduce R:I:IteratePairFromIterator 22:28
travis-ci.org/rakudo/rakudo/builds/173739166 github.com/rakudo/rakudo/compare/6...29aa1bc725
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Give 1dimmed shaped arrays its own .pairs 23:02
travis-ci.org/rakudo/rakudo/builds/173741427 github.com/rakudo/rakudo/compare/e...d9537a7c0a
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 'Introduce R:I:IterateAntiPairFromIterator 23:31
travis-ci.org/rakudo/rakudo/builds/173744416 github.com/rakudo/rakudo/compare/b...c600112561
lizmat
.oO( if I commit often enough, it will pass the build :-)
 23:52
good night, #perl6-dev!
timotimo gnite liz :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!