ShimmerFairy Hm, it seems like partially-dimensioned views of shaped arrays would require some weird fiddling, especially because things like [1;3..5;2] are done as a tree-like series of calls to AT-POS, and that makes creating a "sub-shape" awkward. I can see why it's NYI :) 03:09
(though saying that, I'm now wondering if one could possibly have a 'method subshape' ...)
unmatched} s: HyperWhatever, "new" 03:34
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/c587.../Mu.pm#L83
unmatched} s: HyperWhatever, "new", \() 03:37
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/c587...ver.pm#L10
unmatched} m: HyperWhatever.new 03:39
camelia rakudo-moar c587b9: OUTPUT«WARNINGS for <tmp>:␤Useless use of "new" in sink context (line 1)␤»
unmatched} m: say HyperWhatever.new
camelia rakudo-moar c587b9: OUTPUT«sub (*@_) { #`(Sub|61102224) ... }␤»
unmatched} doesn't get how that happens
It's rt.perl.org/Ticket/Display.html?id=128880
ShimmerFairy unmatched}: one idea would be to --profile it locally and then see the call graph tab to check the chain of functions that's actually called (I'm doing that right now for something I'm playing with) 03:46
the only downside being that you get line numbers for the big huge generated CORE.setting, instead of individual files (but that's always an issue with tracing anything through CORE :P) 03:48
[Tux] This is Rakudo version 2016.07.1-161-gc587b9d built on MoarVM version 2016.07-18-g2f269d8 07:18
csv-ip5xs 10.088
test 15.341
test-t 7.380
csv-parser 16.720
arnsholt jnthn: Are there any semantic differences (LTM-wise, for example), between a method O() that just does a $cursor.'!cursor_pass' and a `token O() { <?> }`? 07:30
gfldex m: my @a = 1..3; my %h; %h{|@a} = 1; dd %h; 07:33
camelia rakudo-moar c587b9: OUTPUT«Hash %h = {"1" => 1, "2" => Any, "3" => Any}␤»
TimToady m: my @a = 1..3; my %h; %h{|@a} = 1 xx *; dd %h; 07:36
camelia rakudo-moar c587b9: OUTPUT«Hash %h = {"1" => 1, "2" => 1, "3" => 1}␤»
gfldex if would expect {|@a} to mean {1;2;3} when it comes to subscripts 07:37
%h{@a}:multi-dim would also make sense 07:38
TimToady m: my @a = 1..3; my %h; %h{||@a} = 1; dd %h; 07:39
camelia rakudo-moar c587b9: OUTPUT«Hash %h = {"1" => 1, "2" => Any, "3" => Any}␤»
TimToady that's supposed to work there, but doesn't
dalek ast: b6012e0 | TimToady++ | S04-statements/sink.t:
RT #127879; map inside sunk 'for' runs as sunk
 07:42
ast: 00dbf5e | TimToady++ | S (3 files):
Merge branch 'master' of git://github.com/perl6/roast
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127879
kudo/nom: 62881ad | TimToady++ | src/Perl6/Actions.nqp:
In general, a method call should want all its args

Fixes "say await start 42".
gfldex m: my @a = 1..3; my %h; %h{;|@a} = 1; dd %h; 07:57
camelia rakudo-moar 7399a3: OUTPUT«Use of Nil in string context in block <unit> at <tmp> line 1␤Hash %h = {"" => ${"1" => ${"2" => ${"3" => 1}}}}␤»
gfldex TimToady: ^^^ that's quite close :) 07:58
m: my @a = 1..3; my %h; %h{;@a} = 1; dd %h; 08:00
camelia rakudo-moar 7399a3: OUTPUT«Use of Nil in string context in block <unit> at <tmp> line 1␤Hash %h = {"" => ${"1" => 1, "2" => Any, "3" => Any}}␤»
gfldex m: multi sub postcircumfix:<{|| }>(\SELF, @indices){ say "oi!" }; my @a = 1..3; my %h; %h{||@a} = 1; 08:03
camelia rakudo-moar 7399a3: OUTPUT«oi!␤Cannot modify an immutable Bool␤ in block <unit> at <tmp> line 1␤␤»
gfldex it's simply not implemented
dalek kudo/nom: 4dd6223 | TimToady++ | src/Perl6/Actions.nqp:
call node inside Want should propage wantedness

This fixes useless use from: my @a; @a.grep({ .value andthen $_ eq "foo" })		 08:07
TimToady m: class Sinker { method sink() { say "Blub" } }; for ^5 { Sinker.new(); }; Nil 08:12
camelia rakudo-moar 4dd622: OUTPUT«Blub␤Blub␤Blub␤Blub␤Blub␤»
TimToady this one is also now fixed
gfldex m: use nqp; multi sub postcircumfix:<{|| }>(\SELF, @indices){my \target = IterationBuffer.new; MD-HASH-SLICE-ONE-POSITION(SELF, @indices, @indices.AT-POS(0), 0, target); nqp::p6bindattrinvres(nqp::create(List), List, '$!reified', target)}; my @a = 1..3; my %h; %h{||@a} = 1; dd %h 08:23
camelia rakudo-moar 4dd622: OUTPUT«Hash %h = {"1" => ${"2" => ${"3" => 1}}}␤»
gfldex i tried to do the same in src/core/hash_slice.pm (plus, a proto and the token in Grammar.nqp) but it's not getting called 08:26
that's the code github.com/gfldex/rakudo/commit/18...2e7de35066 08:29
would be nice if a knowledgable could have a look
m: say &prefix:<||> 09:03
camelia rakudo-moar 4dd622: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ prefix:<||> used at line 1. Did you mean 'prefix:<|>', 'prefix:<~>', 'prefix:<->', 'prefix:<so>'?␤␤»
dalek kudo/nom: 0de8eb3 | lizmat++ | src/core/Set (2 files):
Make Set/SetHash.pairs|antipairs about 10% faster

By using the -> --> sig on the block		 09:41
kudo/nom: 6c7eb38 | lizmat++ | src/core/Str.pm:
Make Str.comb(Regex) a bit faster
kudo/nom: 4cef9ee | lizmat++ | src/core/Promise.pm:
Make sure we can return Nil as a result of Promise
 10:48
|Tux| This is Rakudo version 2016.07.1-172-g4cef9ee built on MoarVM version 2016.07-18-g2f269d8 11:30
csv-ip5xs 9.856
test 15.284
test-t 7.293
csv-parser 16.094
lizmat [Tux] I think I now have some ways of making Text::CSV faster, but it would require some changes in the Text::CSV code 11:31
|Tux| lizmat, 4.2% to go to get under 7
lizmat still Perl 6 only features though :-)
|Tux| go ahead 11:32
nine I'm sure all other incarnations have been optimized to death already, so why not the Perl 6 one :) 11:34
lizmat |Tux| ok, that was disappointing :-( 11:44
somehow the for @a -> \x --> Type { } takes longer than just for @a { } 11:54
basically nulling out the whole optimization of not having to looking for Slips 11:55
nine lizmat: that's odd. The same changes in Set/SetHash seem to have improved performance? 12:36
lizmat well, I'm not so sure anymore :-( 12:37
anyways, it's a long ways away from 30% of quickmap :-(
guess I will have to be more patient
and less doctor
m: my @a = ^100000; my $b = now; for @a { .Str }; say now - $b # standard way 12:43
camelia rakudo-moar 4cef9e: OUTPUT«0.1266844␤»
lizmat m: my @a = ^100000; my $b = now; for @a -> \x --> Str { x.Str }; say now - $b # optimized way
camelia rakudo-moar 4cef9e: OUTPUT«0.0802056␤»
lizmat so that *does* seem to help 12:44
apart from being a longwinded way to say the same
m: say 0.1266844 / 0.0802056 12:45
camelia rakudo-moar 4cef9e: OUTPUT«1.5794957␤»
nine m: my @a = ^100000; my $b = now; for @a { .Str }; say now - $b 12:49
camelia rakudo-moar 4cef9e: OUTPUT«0.1280199␤»
nine m: my @a = ^100000; my $b = now; for @a -> \x --> Str { x.Str }; say now - $b
camelia rakudo-moar 4cef9e: OUTPUT«0.08233568␤»
nine Yep, well reproducible
And yes, it's a shame that the shorter version is slower. But I can't seem to find a better solution either.
lizmat I guess we need the optimizer to introspect the block and decide .Str is the only thing that can be returned 12:50
and set the block.returns for us
I guess actually in the case of *.Str we can already do that 12:51
nine s/optimizer/spesh/
lizmat in the case of *.Str, it would be compile time doable no? 12:52
nine As the .Str is a method call the optimizer cannot statically decide what the return value will be. Spesh should be able to.
unmatched} What does "spesh" stand for?
nine x could have a Str method that returns a Slip :)
lizmat ah, yes, good point 12:53
nine unmatched}: I think type specializer or something like that
lizmat but then, how could spesh then do it reliably
unmatched} ah
nine lizmat: AFAIK observe that this always returns Strs, specialize for Str and add a guard op, so if the behavior suddenly changes we fall back to the unspecialized code 12:55
lizmat nine: ack
hmmm... aren't blocks supposed to be immutable at runtime? 12:59
*can* we actually change the .returns on a Block ?
jnthn .tell ShimmerFairy fwiw, on partially dimensioned views, I'd somewhat expected to do them by way of there being a VM-level mechanism which gives you a "view" into another array, essentially currying a dimension or two. 13:03
yoleaux2 jnthn: I'll pass your message to ShimmerFairy.
RabidGravy I have actually wanted to do that in the past
then got over it
jnthn lizmat: The return type should be fixed in place from the point the routine's closing curly has been parsed. 13:04
lizmat ok, so spesh messing with the return type is a no go
ShimmerFairy jnthn: ah. I've started trying something, but VM-level "view" for what's effectively a VM-level construct would make more sense :) 13:05
jnthn lizmat: If you do change it then it'll only make a different for introspection purposes, I expect, 'cus the check gets compiled into the code.
yoleaux2 13:03Z <jnthn> ShimmerFairy: fwiw, on partially dimensioned views, I'd somewhat expected to do them by way of there being a VM-level mechanism which gives you a "view" into another array, essentially currying a dimension or two.
lizmat so we need another way to get the faster iterator
jnthn spesh doesn't care in the slightest about what a Perl 6 signature object says, it cares what the bytecode says :)
ShimmerFairy especially since finding the right places to do it in rakudo code is quite awkward.
jnthn ShimmerFairy: Yeah, I'd expect that to be less than fun :)
lizmat jnthn: ah, but the iterator selection *is* done through introspection atm
arnsholt jnthn: A <?> assertion in a regex just compiles down to a `$cursor.'!cursor_pass'(...)`, right? 13:06
jnthn lizmat: That's fine, I'm just saying that if somebody changes the return type somehow at runtime, then it'd affect introspection only. But that's very far into DIHWIDT land ;)
ShimmerFairy And I was currently only working on the @array[4] case, and not yet the @array[1..3;4;*;3] case :P
jnthn arnsholt: Just saw that question in the backlog. Effectively, yes. 13:07
arnsholt Kewl. 'Cause then I can simplify HLL::Grammar.O even more
jnthn :)
arnsholt The fewer methods in HLL::Grammar, the better IMO
jnthn ShimmerFairy: fwiw, I'd got other use-cases in mind for a VM-level view thingy too. subbuf for example :) 13:08
ShimmerFairy: Though probably only on immutable blobs
ShimmerFairy jnthn: something felt off about doing it in P6 land anyway (especially the prospect of throw-away shaped arrays in one possible implementation for infix:<[; ]>). 13:09
jnthn: and the reason I'm suddenly interested in this is because the ad-hoc @a = [1,2],[4,5] doesn't feel as good for my use-case (a fixed 3D array), so I guess I'm prepared to make partial dimensioning work :P 13:11
jnthn ShimmerFairy: Yeah, I did think about it when doing the design work and figured it'd be most naturally handled down at VM level 13:13
ShimmerFairy jnthn: Like I said, definitely can see why that's the case. The VM level doesn't have a bunch of P6-level stuff to be worried about at the same time (MMD, operators, and so on) 13:16
jnthn Right :) 13:17
Also, the multi-dim stuff is designed so the dimensionality is part of the type
Which will let us do really nice branch-free JIT of multi-dim array lookups in the future.
So we'd want to try and carry that through to the view thingy also 13:18
ShimmerFairy jnthn: one thing I noticed is that there'll be a discrepancy between @a[1;5;2] for unshaped and shaped arrays, where the shaped version returns something also shaped, but the unshaped version currently returns a flat structure. I'm not sure how I feel about that. 13:19
jnthn I think "also shaped" probably makes sense 13:21
Consider
my @a[3;3;3]; sub foo(@b[*;*]) { }; foo(@a[1]) 13:22
Or similar
We'd quite like that to work
ShimmerFairy oh, I wasn't suggesting the shaped path was wrong, but rather it feels weird that the unshaped version returns something totally flat regardless 13:23
jnthn And the signature check there is a declarative thing (tests .shape), not looking at the data shape
Got a concrete example of a case where it'd trip somebody up?
ShimmerFairy m: my @a = [1,2],[4,5]; say @a[*;1]; # part of me wonders if this wouldn't want to be [2],[5] instead 13:24
camelia rakudo-moar 4cef9e: OUTPUT«(2 5)␤»
ShimmerFairy jnthn: not at the moment, and .rotor() is always there to get back the structure you'd like to have (or just use shaped arrays, in the future ☺)
jnthn m: my @a[2;2] = [1,2],[4,5]; say @a[*;1] 13:26
camelia rakudo-moar 4cef9e: OUTPUT«Partially dimensioned views of arrays not yet implemented. Sorry. ␤ in block <unit> at <tmp> line 1␤␤»
jnthn Aww, right :)
ShimmerFairy yeah, trying that gets you that tree-like AT-POS call structure :P
jnthn But since we're reached the leaves, would the result not be(2 5)?
s/be(/be (/
ShimmerFairy True, I may be a bit too tired at this point to remember why exactly I'd like e.g. @mtx3d[0;*;0] to not be a flat list :) 13:28
jnthn :)
Yeah, my initial thinking was that if you are indexing in a way that you provide a value for all dimensions of the declared shape, then you'd get a flat list. 13:29
That is, that we need partially dimensioned views to compute @a[*;1] is really an implementation detail
It's not that I'd expect to get one back
@a[*] I would because I've missed out a dimension 13:30
ShimmerFairy I think it's more pertinent for 2D views, that's what it was. So, @a[0;*;*] would ideally be a not-flat thing in every case 13:31
m: my @a = [[1,2],[4,5]],[[6,7],[8,9]]; say @a[*;0;*];
camelia rakudo-moar 4cef9e: OUTPUT«(1 2 6 7)␤»
ShimmerFairy yeah, that's the case where the unshaped indexing seems like it will end up being at odds with what a shaped index would do.
jnthn I don't immediately see why; I tend to think of @a[*;0;*] being short-hand for (@a[0;0;0], @a[0;0;1], @a[1;0;0], @a[1;0;1]) 13:37
And, after all, if you *do* want to know the paths to the elements, then my can write @a[*;0;*]:p or @a[*;0;*]:kv
ShimmerFairy hm, :p and :kv don't work on unshaped arrays 13:38
jnthn m: my @a = [1,2],[3,4]; dd @a[*;1] 13:40
camelia rakudo-moar 4cef9e: OUTPUT«(2, 4)␤»
jnthn m: my @a = [1,2],[3,4]; dd @a[*;1]:kv
camelia rakudo-moar 4cef9e: OUTPUT«Unexpected named parameter 'kv' passed␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: my @a = [1,2],[3,4]; dd @a[*;1]:p
camelia rakudo-moar 4cef9e: OUTPUT«Unexpected named parameter 'p' passed␤ in block <unit> at <tmp> line 1␤␤»
jnthn Ah, don't work as in NYI. :)
Yeah...but I think we can agree they really should work? :)
m: my @a[2;2] = [1,2],[3,4]; dd @a.kv 13:41
camelia rakudo-moar 4cef9e: OUTPUT«((0, 0), 1, (0, 1), 2, (1, 0), 3, (1, 1), 4).Seq␤»
ShimmerFairy jnthn: I'm not sure what they're expected to do, but if they can easily give me that structured view I'd like, then it's good :)
ah, I see
jnthn I'd expect @a[*;*]:kv to produce output like that, I think
I'm wondering if you have a distinct use-case though
Which actually cross-cuts whether the thing is declared shaped/unshaped 13:42
ShimmerFairy jnthn: in this case, it's trying to implement the SHA-3 algorithm, which conceptually has a 3D state array that you take different views of. (Let me find a link to the diagram, if I can.)
jnthn That is, you want the original structure but trimmed to include the indices described?
ShimmerFairy keccak.noekeon.org/Keccak-f-PiecesOfState.png 13:43
I don't think the mathematics actually cares that much if you get the view, it's just a concern that came up while implementing a class to handle it :)
jnthn Ah, interesting :)
I get the use-case now, at least... :) 13:45
ShimmerFairy fwiw, the algorithm insists on putting the origin X and Y coordinates in the center of that diagram, but it doesn't matter to the actual algorithm either (near as I can tell so far).
Like I said, rotor-ing isn't that bad anyway :) 13:46
jnthn Aye :)
Lunch time for me...back later :)
ShimmerFairy (honestly, having .rotor built-in is *super* nice, this would be a much bigger annoyance without it) 13:47
lizmat afk& 14:09
unmatched} .tell lizmat if you're looking for content for the Weekly, we got a new bot: SourceBaby. You trigger it with s: trigger, giving it arguments to give to CoreHackers::Sourcery's sourcery() sub and it gives a GitHub URL to source in question. 15:12
yoleaux2 unmatched}: I'll pass your message to lizmat.
unmatched} s: Int, "base", \(16)
SourceBaby unmatched}, Something's wrong: ␤ERR: Could not find candidate that can do \(16)␤ in sub sourcery at /home/zoffix/services/lib/CoreHackers-Sourcery/lib/CoreHackers/Sourcery.pm6 (CoreHackers::Sourcery) line 29␤ in block <unit> at -e line 6␤␤
unmatched} s: 42, "base", \(16)
SourceBaby unmatched}, Sauce is at github.com/rakudo/rakudo/blob/4cef...Int.pm#L63
unmatched} And it refreshes the rakudo build every hour 15:13
unmatched} leaves for a few days to study up the Internals course and how MoarVM works
\o
lucs unmatched}: Don't forget to blog about it! Have fun :) 15:14
perlpilot s: Int abs 15:16
SourceBaby perlpilot, Something's wrong: ␤ERR: ===SORRY!=== Error while compiling -e␤Unable to parse expression in argument list; couldn't find final ')' ␤at -e:6␤------> put sourcery( Int⏏ abs )[1];␤ expecting any of:␤ infix␤ infix stopper␤
dalek p: 05e51ee | (Zoffix Znet)++ | docs/6model/overview.markdown:
Fix typo
 16:30
arnsholt jnthn: Except O doesn't actually attach its information to the AST slot, but to the *match* slot, so my simplification doesn't work. I'm half inclined to refactor everything to use .made instead. Thoughts?
jnthn: I guess it might increase parsing overhead, which would be bad for large compilations like the Rakudo setting? 16:34
dalek p: 5b4fcb5 | (Zoffix Znet)++ | docs/qast.markdown:
Fix formatting

POD syntax used in Markdown document.		 16:36
jdv79 SauceBaby would be a more amusing name but in any case "Baby" with anything seems a bit strange to me. 16:55
timotimo oh, saucebaby, like a baby sitting at one of those baby chairs with a table built-in and just sloshing sauce and soup and carrots all over the place 16:56
nine [Tux]: please try installing Inline::Perl5 again. It should install now on perls with uselongdouble :) 16:59
[Tux]: some problems suddenly appear ridiculously simple once you know a solution... 17:00
jnthn arnsholt: I'm not sure, but it may make sense. fwiw, the fact that places we expect to contain Match objects can suddenly contain a Hash is not only the cause of an extra test on a hot path, but also one of the most common sources of deoptimization (because it's a Match object most of the time, and deopts on the Hash case) 17:37
arnsholt jnthn: Oh, that's interesting. In that case, I'll implement it and see what falls out 17:42
gfldex is there any documentation on how to untangle NQPMatch? 18:49
i basically got the top of gist.github.com/gfldex/ba813b6f0e4...ffcc04b773
and I need to know if there is 'EXPR: ||'
TimToady is there some particular reason CATCH doesn't work inside List.invert? 18:59
or at least, why it doesn't work to catch Method 'value' not found for invocant of class 'Int' 19:00
[Coke] there's not a lot of moving parts in List.invert 19:01
[Tux] nine, you should probably increase its version 20:01
All tests successful.
Files=30, Tests=381, 29 wallclock secs ( 0.11 usr 0.02 sys + 26.41 cusr 1.18 csys = 27.72 CPU)
Result: PASS
==> Installing Inline::Perl5
jnthn TimToady: You're not getting caught out by map being lazily evaluated? 20:08
Hm, I'm not at HEAD but List.invert here looks like `self.map({ nqp::decont(.value) »=>» .key }).flat`
arnsholt jnthn: The coercion thing you mention, would that be Perl6::Grammar.AS_MATCH? 20:09
jnthn So a CATCH inside the method wouldn't help 'cus it's out of dynamic scope before something evaluates the thing
arnsholt: Coercion thing? 20:10
arnsholt Sorry
You said something about places which expect a Match object but getting Hash objects
(In re O being more like normal rules)
And I just found AS_MATCH in the Rakudo grammar, which looks suspiciously similar to what you talked about 20:11
jnthn Oh, I was talking about
github.com/perl6/nqp/blob/master/s...r.nqp#L918
Note the hash handling there too
arnsholt Oh, right. That's even hot-pathier
jnthn I *think* there's another place that has to cope too but I don't immediately see it... 20:12
arnsholt It's checking for the thing being *not* a hash though, isn't it? 20:13
[Tux] nine++, Inline::Perl5 passes all CSV tests with -Duselongdouble 20:18
This is Rakudo version 2016.07.1-172-g4cef9ee built on MoarVM version 2016.07-18-g2f269d8 20:19
csv-ip5xs 10.085
test 15.403
test-t 7.439
csv-parser 16.674
jnthn arnsholt: Yes 20:20
arnsholt Oh, right. Because a hash in that position has is also a valid "match" object 20:24
My brains are a bit addled, it seems
I'll keep digging into this in the morrow. Thanks for the help!
jnthn Thanks for working on it :) 20:26
perlpilot random though because I clicked on the link: What does it check to see if it's not an NQPMatch too? What else is being stored in $!match? 20:27
s/What/Why/
dalek kudo/nom: be7ce04 | lizmat++ | src/core/REPL.pm:
Make the REPL catch CONTROL-c when executing

Pressing CONTROL-c while something is executing, will not wait for the result of that code to appear. The code *will* however continue to execute at the moment, because we do not have a way to force an exception to be thrown in another thread.
Fixes RT #128900 *and* RT #128595		 20:32
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128900
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128595
lizmat hmmm... the RT #128595 still exists, the test is just not up to par :-( 20:38
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128595
yoleaux2 15:12Z <unmatched}> lizmat: if you're looking for content for the Weekly, we got a new bot: SourceBaby. You trigger it with s: trigger, giving it arguments to give to CoreHackers::Sourcery's sourcery() sub and it gives a GitHub URL to source in question.
jnthn perlpilot: Because O has been storing a Hash in there so far, to date. Why it does this, I'm not entirley sure; it's been that way sufficiently long it may date back to before my time in Perl 6. Certainly before the time when I understood the grammar engine. :-) 20:51
*entirely
TimToady jnthn: doh! of course it's a lazy list... 22:14
gfldex m: my %h; %h{1;2} = 42; say %h{1;2}:exists; 22:19
camelia rakudo-moar be7ce0: OUTPUT«Unexpected named parameter 'exists' passed␤ in block <unit> at <tmp> line 1␤␤»
unmatched} The test for 128595 tests just for the "not-hangingness" of the REPL. Not sure why I thought that was a good idea, considering bailing out and not starting a REPL (just like not executing any -e '' code) on missing modules is the right way to go :/ 22:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!