Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
Geth rakudo: jstuder-gh++ created pull request #2425:
Fix potential race condition in Proc::Async start		 03:10
lizmat Files=1257, Tests=76342, 337 wallclock secs (15.69 usr 5.66 sys + 2372.09 cusr 241.51 csys = 2634.95 CPU) 06:58
Geth rakudo: 79bec897f5 | (Zoffix Znet)++ | appveyor.yml
Revert to non-verbose nmake test

No idea how to get the prove command to work right on appveyor		 09:58
lizmat bisectable6: dd sub (Str(Int) $a, Int $b ) { }.assuming(1).signature 11:26
bisectable6 lizmat, On both starting points (old=2015.12 new=79bec89) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «:(Int $b)␤»
lizmat bisectable6: dd sub (Str(Int) $a, Str(Int) $b ) { }.assuming(1).signature 11:29
bisectable6 lizmat, On both starting points (old=2015.12 new=79bec89) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «:(Int $b)␤»
lizmat that seems wrong to me :-)
Geth rakudo: lizmat self-assigned Code.assuming doesn't honour coerce_type Parameters github.com/rakudo/rakudo/issues/2426
97996e5e9a | (Elizabeth Mattijsen)++ | src/core/Code.pm6

Fixes R#2426		 11:39
lizmat m: sub a (Str(Int) @a) { dd @a }; a Array[Int].new(1,2,3) # this is not what I expected 12:00
camelia "1 2 3"
lizmat jnthn moritz masak ^^^ is that to be expected ? 12:02
I sorta expected an array of strings with "1","2","3"
perhaps we should disallow coercion on aggregate types? until we've figured out the semantics ? 12:03
Zoffix lizmat: FWIW, I would've expected an Array parametarized with Str(Int) type, though I think that hits whatever limitation prevents `my Str(Int) $x` from working. 12:05
lizmat: there's a ticket with a similar example: R#2319
synopsebot R#2319 [open]: github.com/rakudo/rakudo/issues/2319 Coercers as parameter parametarizers give wild results
Zoffix m: -> Int() @v { dd @v.^name }(Array[Any].new: 1, 2, 34, 6) 12:06
camelia "Int"
Zoffix "an Array parametarized with".. I mean for the signature to only accept such an Array 12:07
m: dd Array[Str(Int)].new
camelia Array[Str(Int)].new()
Zoffix m: dd Array[Str(Int)].new: 42, 55 12:08
camelia Type check failed in assignment to ; expected Str(Int) but got Int (42)
in block <unit> at <tmp> line 1
Zoffix heh
m: dd Array[Str(Any(Cool(IO(Array[Str(Any(Cool(IO(Int))))]))))].new: 42, 55 12:09
camelia Type check failed in assignment to ; expected Str(Any(Cool(IO(Array[Str(Any(Cool(IO(Int))))])))) but got Int (42)
in block <unit> at <tmp> line 1
Zoffix m: -> Str(Int(Cool)) $x { dd $x }(42)
camelia Type check failed in binding to parameter '$x'; expected Int(Cool) but got Int (42)
in block <unit> at <tmp> line 1
Zoffix Filed as R#2427 12:12
synopsebot R#2427 [open]: github.com/rakudo/rakudo/issues/2427 Nested Coercers
synopsebot R#2426 [open]: github.com/rakudo/rakudo/issues/2426 Code.assuming doesn't honour coerce_type Parameters
Geth rakudo: lizmat self-unassigned Code.assuming doesn't honour coerce_type Parameters github.com/rakudo/rakudo/issues/2426
1ea3ff2fb2 | (Elizabeth Mattijsen)++ | src/core/Code.pm6

That are not yet picked up in codegen or by the static optimizer yet :-(		 12:31
jnthn lizmat: Forbidden for now, I think 13:17
dogbert2_ jnthn: back from your trip? 13:55
jnthn dogbert2_: Yeah...with a cold-ish thing :/ 14:00
pmurias m: multi y(int $x is rw) { say('good') }; multi y(Int $x) { say('bad') }; y(my int $x = 42); 14:14
camelia bad
pmurias jnthn: ^^ is this a bug?
jnthn Looks like, yes
pmurias m: multi y(int $x is rw) { 'good' }; multi y(Int $x) { 'bad' }; say "optimizer has different semantics:", y(my int $x = 42); 14:15
camelia optimizer has different semantics:good
jnthn The "optimizer" can settle literal allomorphy 14:17
But in this case it's just a straight native reference and that should do the right thing at runtime
I think we'll rename the optimize phase also 14:18
Because it'll increasingly do spec things
And the name should reflect that
Optimizer implies it's entirely optional, which is the source of a lot of confusion.
pmurias jnthn: if it starts doing spec things it should do them in consistent manner rather then based on adhocly gathered info ;) 14:25
jnthn Please stop trying to have the same discussion 2000 times. 14:28
timotimo we can call it the CHECKer, since it runs at check time ... or does it actually run earlier than that?
i think CHECK is kind of like link time?
jnthn It comes after CHECK 14:29
Since CHECK is your last chance to do things before we make assumptions about things not changing.
timotimo it's the baker
dogbert2_ jnthn: oops, cold-ish things are not very nice 14:48
pmurias jnthn: the problem is that nqp::isrwcont(nqp::captureposarg($capture, $index)) return 0 for a int lexicalref 15:30
jnthn Ah. That's wrong. 15:36
Odd... github.com/MoarVM/MoarVM/blob/mast...ers.c#L352 15:40
That looks correct
timotimo perhaps the struct below is messed up in its order … 15:41
easy to check with gdb
yeah it's correct
timotimo jnthn: i'm seeing that we're not setting rw_cont in the type tuple if we have a NativeRef ... is the distinction between a "scalar that's RW" and "a native ref" important? 16:07
i stumbled across it because the decontrv for those still have an isrwcont op in them 16:08
so we're not setting the RW_CONT fact in spesh for those cases
jnthn timotimo: It should be set, but it exposes some other shortcomings that need to be addressed first. 16:09
timotimo right, like we'd have the "is rw cont" flag set, but there wouldn't be a cont type vs decont type
or rather, we don't have a way to signal "decont on this will box, if you don't want it, here's the op that you want instead" 16:10
i've got a patch that will split a decont on a NativeRef into a decont_* plus a box_*
that devirtualizes "what kind of object do we have, how do i properly unbox it" plus the creation of the box object is either split into a fastcreate and a sp_bind_* 16:11
and that should allow for scalar replacement or box removal, too 16:12
timotimo i was considering maybe adding a spesh op that can add an i to an I - mostly just because you can swap the LHS and RHS of an add_I 16:13
jnthn Ooh, yes :)
(to the first opt)
Not sure on the second one
Though I guess maybe it makes ++ and -- cheaper
timotimo it can improve our performance when we add an Int and an Int*Ref 16:14
right now we're deconting the ref into a boxed object, then add_I (or whatever) 16:15
we could skip that box
jnthn True, but maybe SR will do that for us anyway
timotimo that'd be cool.
jnthn My plan is to try and let us store a P6bigint in a register (
timotimo i have a snippet in front of me right now that looks like something we should totally be able to do either already or very soon
jnthn Only spesh-done of course, not exposed 16:16
timotimo sp_bind_s_nowb r9(5), liti16(32), r40(1)
jnthn We need to be super careful not to leak though
timotimo sp_p6oget_s r13(2), r9(5), liti16(8)
aye, that'd be very bad news
i'm not sure how the 8 and 32 correspond there, though
jnthn Offset from start of object vs. offset from data part of a P6opaque 16:17
timotimo ooh 16:18
one includes the header, then
and the other might go through an indirection
maybe this discussion ought to move to #moarvm 16:19
[Tux] Rakudo version 2018.09-510-g97996e5e9 - MoarVM version 2018.09-139-g8b4d58c7a
csv-ip5xs0.902 - 0.915
csv-ip5xs-207.731 - 7.731
csv-parser22.117 - 23.090
csv-test-xs-200.432 - 0.454
test8.897 - 9.355
test-t1.733 - 1.811
test-t --race0.833 - 0.836
test-t-2030.355 - 33.189
test-t-20 --race11.829 - 12.357
 17:34
lizmat jnthn: re 'my Str(Int) @a', perhaps we could allow that by adding another role that takes 2 types: the constraint and the coercion type 20:04
the coercion type would be in the descriptor, and the whole type would be in the candidates ? 20:05
m: role a[::T] { method a(T $a) { dd $a } }; dd a[Str(Int)].new.a(42) # perhaps more work is needed there :-) 20:07
camelia Type check failed in binding to parameter '$a'; expected Str(Int) but got Int (42)
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn lizmat: It's more that we'd want to allow Array[Str(Int)] to exist in the first place 20:55
lizmat: Which is a much more accessible task since the assignment refactors 20:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!