ugexe m: grammar Foo { token TOP { <return> }; token return { .+ }; }; Foo.parse(1); # bug? or dihwidt? 00:33
camelia rakudo-moar 6df7ff: OUTPUT«Attempt to return outside of any Routine␤ in any !cursor_pass at /home/camelia/rakudo-m-inst-1/share/nqp/lib/QRegex.moarvm line 1␤ in regex return at /tmp/aWitnhteKS line 1␤ in regex TOP at /tmp/aWitnhteKS line 1␤ in block <unit> at /tmp/aWitnh…»
00:42 skids joined 01:50 lizmat joined 02:05 sortiz joined 05:03 vendethiel joined 06:53 RabidGravy joined
[TuxCM] This is Rakudo version 2016.04-2-g6df7ff8 built on MoarVM version 2016.04 07:36
test 22.332
test-t 12.728
csv-parser 25.649
masak ugexe: surprising, at least. a token is a kind of method, so why would that clash at all with `return` as a sub? 07:59
m: grammar Foo { token TOP { <return> } }; Foo.parse("1") 08:01
camelia rakudo-moar 6df7ff: OUTPUT«Attempt to return outside of any Routine␤ in regex TOP at /tmp/pIS3uINPSr line 1␤ in block <unit> at /tmp/pIS3uINPSr line 1␤␤»
masak ugexe: I think the problem isn't the declaration of `token return`, but the call `<return>`, which looks both for subs and methods... perhaps?
and since there is a lexical sub &return, it finds it
jnthn m: grammar Foo { token TOP { <return> } }; Foo.parse("1", actions => class { method return($/) { } }) 08:19
camelia rakudo-moar 6df7ff: OUTPUT«Attempt to return outside of any Routine␤ in regex TOP at /tmp/xVJZheFumA line 1␤ in block <unit> at /tmp/xVJZheFumA line 1␤␤»
jnthn masak: But it's only meant to find things of type Regex, I thought...
jnthn had suspected it was calling .return 08:20
As an action method
But apparently not, O did the action method wrong
masak so... I submit a rakudobug? 08:33
08:53 lizmat joined
masak submits rakudobug 08:55
09:02 tadzik joined
tadzik o/ 09:03
lizmat tadzik o/ 09:19
lizmat waves from the QA Hackathon in Rugby
09:19 brrt joined
bartolin o/ lizmat (just remembered last years QAH -- fond memories :-) 09:23
lizmat bartolin o/ 09:24
RabidGravy lizmat, be sure to check out the weird conical hills dotted around 09:35
jnthn waves to folks at the QAH
lizmat
.oO( those hills look fummy )
 09:36
masak hi, QAH people 09:42
wish I could be there 09:43
dalek kudo/nom: a0a1e95 | lizmat++ | src/core/Main.pm:
my ($a,$b) is 10x slower than my $a; my $b
jnthn lizmat: Even if you don't assign? 09:44
lizmat yes
jnthn Hm, that really wants fixing :)
lizmat m: for ^10000 { my ($a,$b) }; say now - INIT now
camelia rakudo-moar 6df7ff: OUTPUT«0.02808860␤»
lizmat m: for ^10000 { my $a; my $b }; say now - INIT now 09:45
camelia rakudo-moar 6df7ff: OUTPUT«0.0051890␤»
tadzik so, there's this idea to make it easier for users to have the MAIN they expect to have, that actually allows named after positional arguments 09:46
so lizmat++ is now moving stuff from MAIN_HELPER to Rakudo::Internals so it's easier for people to write their own MAIN_HELPER without copypasting the entire thing from the setting 09:47
10:02 perlpilot_ joined 10:14 dalek joined
masak yay 10:18
named arguments after positional arguments would be verra nice 10:19
timotimo agreed 10:23
i remember the thing in some software that grepped everything that starts in two dashes and puts it in front
tadzik I'd also happily poke someone's brane about grammars and parsing :) 10:24
panda used to do that
timotimo and the obvious problem with that was named parameters with vs without parameters
tadzik right
question is, does the regular main even do that? 10:26
it seems to only notice when you do --foo=bar 10:27
10:28 sno joined
tadzik so the reordering trick is actually quite foulproof in that regard after all 10:29
10:36 brrt joined
tadzik oh, fun fact: spectests talk about the irc conversation to remove this, since it's a fossil 10:37
the conversation is from 2011 :) irclog.perlgeek.de/perl6/2011-10-17#i_4578353
seems to be gone since nom is a thing
RT #124664
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124664
tadzik hugs synopsebot6 (IRC)
so, I have this: gist.github.com/tadzik/876ad5e3e01...24b7de3d8a 10:51
and it doesn't seem to break spectests
dalek ast: 222aa2d | usev6++ | S32-io/IO-Socket-Async.t:
Skip test for 'bytes-supply' on JVM

  ... because it often hangs in spectests		 11:00
jnthn Those of you with a good memory: did we at some point have / are we still having some unreliability in nativecall union related tests? 11:09
tadzik RT #71366 11:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=71366
lizmat m: role A { method a { ::?ROLE } }; dd A.a =:= A # shouldn't this be True ? 11:19
camelia rakudo-moar a0a1e9: OUTPUT«Bool::False␤»
lizmat jnthn: ^^^ 11:20
moritz lizmat: no
erm, not sure
lizmat :-) 11:21
moritz one of them might refer to the punned class, not to the role
jnthn No
What moritz said
Oh, actually
moritz though I don't know how to reason about what A refers to
jnthn It's a tad more involved than that
moritz role A { method a { ::?ROLE } }; dd A.a =:= A; say A.HOW.^name
m: role A { method a { ::?ROLE } }; dd A.a =:= A; say A.HOW.^name
camelia rakudo-moar a0a1e9: OUTPUT«Bool::False␤Perl6::Metamodel::ParametricRoleGroupHOW␤»
jnthn m: role A { method a { say ::?ROLE.HOW.^name } }; A.a 11:22
camelia rakudo-moar a0a1e9: OUTPUT«Perl6::Metamodel::ParametricRoleHOW␤»
jnthn Right, it's the group/candidate distinction
moritz m: role A { method a { say ::?ROLE.HOW.^name } }; A.a; say A.HOW.^name
camelia rakudo-moar a0a1e9: OUTPUT«Perl6::Metamodel::ParametricRoleHOW␤Perl6::Metamodel::ParametricRoleGroupHOW␤»
moritz RoleHOW vs. RoleGroupHOW
it seems that ::?ROLE refers to the candidate, and the name to the "proto"
lizmat then we have a faulty spectest.. :-)
in t/spec/S12-class/magical-vars.t 11:23
and possibly more of that type 11:24
dalek kudo/nom: fe2be65 | lizmat++ | src/core/ (4 files):
=== should fail if not identical types

  irclog.perlgeek.de/perl6/2016-04-19#i_12363756
This breaks some spectests. Since we're just after the release, I'm going to leave them for now, hoping someone else will look at the failures.		 11:27
ast: d4dd5a5 | lizmat++ | S03-operators/value_equivalence.t:
Unfudge now passing test
 11:29
11:37 geekosaur joined 11:54 astj joined
dalek ast: e5b428d | lizmat++ | S (6 files):
Adjust tests because of fe2be65806d907efbbaa
 11:55
ast/6.c-errata: 2199588 | lizmat++ | S (6 files):
Adapt tests because of fe2be65806d907efbbaa
 11:58
ast: c816aad | usev6++ | S (2 files):
Add ticket numbers for skipped tests (JVM)
 12:21
nine_ IIRC it's quite easy to change MAIN to accept optionals both before and after positionals 12:36
12:49 brrt joined 12:53 [TuxCM] joined
dalek ast: 1da9613 | usev6++ | S02-literals/allomorphic.t:
Add ticket number for skipped test (JVM)
 12:56
tadzik nine_: from the user side? 13:33
nine_ tadzik: unfortunately not :/ AT least not without copying the code. 13:38
tadzik nine_: yeah, from within rakudo it was a 3 line patch 13:39
but since we don't accept "--argument value" now, only "--argument=value", the hack for reordering @*ARGS that panda did is actually still valid it seems
btw, I heard rumours of a document that talks in detail about CUR and Distribution and stuff: does anyone have a link to it? 13:40
13:41 skids joined
nine_ doc/module_management.md? 13:45
tadzik （´ー｀　） 13:47
thanks
stmuk is someone able to progress the R* release based on pl6anet.org/drop/rakudo-star-2016.04-RC1.tar.gz please 13:48
its been out a day and I suspect anyone who has dl'd is likely to have done so
14:01 geekosaur joined
tadzik nine_: was the conclusion re Distribution that each module installer is supposed to implement it itself, perhaps consuming a role that's core? 14:06
nine_ tadzik: there's an open pull request moving us in that direction, yes 14:08
tadzik I see, neat 14:10
14:33 geekosaur joined
lizmat m: class A { method a { $!a }; has $!a } # why does this even compile ? 14:40
camelia ( no output )
lizmat m: class A { method a { $a }; my $a } # this doesn't
camelia rakudo-moar fe2be6: OUTPUT«===SORRY!=== Error while compiling /tmp/JdjwqsJRd6␤Variable '$a' is not declared␤at /tmp/JdjwqsJRd6:1␤------> class A { method a { ⏏$a }; my $a } # this doesn't␤»
masak lizmat: I could rationalize why the first one works and the second one doesn't -- but I don't know if doing so is better than conservatively saying that the first one is wrong. 14:41
jnthn It works because we check the set of attributes at class compositon time 14:42
And we check them at class composition time because that's when role composition happens
Back when you could not refer to attributes from roles inside of classes, they behaved like `my`
Anyway, "because attributes come from roles, their symbol availability is not lexical" is a decent summary 14:43
lizmat but if you would set up a class with the roles specified at class start, you would be able to tell whether an attribute existed or not?
ok, this was in relation to rt.perl.org/Ticket/Display.html?id=127950 14:44
jnthn No, because genericity
lizmat ok 14:45
jnthn We don't actually know precisely which role we'll be doing until we do the multi-dispatch on the role group 14:46
lizmat so we basically need to annotate attributes lines/columns whenever we encounter them to be able to create an error with a line number ?
jnthn Yeah...we already have a data structure where we track unresolved attributes 14:47
iirc :)
14:53 brrt joined
lizmat m: my $a = 42; say $a =:= $a; say $a.WHAT =:= $a.WHAT; say $a == $a; say $a =:= $a || $a.WHAT =:= $a.WHAT # where does the 1 come from ??? 16:01
camelia rakudo-moar fe2be6: OUTPUT«True␤True␤True␤1␤»
jnthn m: my $a = 42; say $a =:= $a || $a.WHAT =:= $a.WHAT 16:03
camelia rakudo-moar fe2be6: OUTPUT«1␤»
jnthn m: my $a = 42; say ($a =:= $a) || ($a.WHAT =:= $a.WHAT)
camelia rakudo-moar fe2be6: OUTPUT«1␤»
jnthn m: my $a = 42; say 0 || ($a.WHAT =:= $a.WHAT)
camelia rakudo-moar fe2be6: OUTPUT«True␤»
jnthn m: my $a = 42; say ($a =:= $a) || (say 'huh')
camelia rakudo-moar fe2be6: OUTPUT«1␤»
jnthn m: my $a = 42; say $a =:= $a
camelia rakudo-moar fe2be6: OUTPUT«True␤»
jnthn m: my $a = 42; say ?($a =:= $a) 16:04
camelia rakudo-moar fe2be6: OUTPUT«True␤»
jnthn m: my $a = 42; say do unless $a =:= $a { 'x' }
camelia rakudo-moar fe2be6: OUTPUT«()␤»
jnthn lizmat: I...have no idea!
Does it show up with --optimize=off?
lizmat do you agree this is spooky?
jnthn Yes :)
m: my $a = 42; say (($a =:= $a) or ($a.WHAT =:= $a.WHAT)) 16:05
camelia rakudo-moar fe2be6: OUTPUT«1␤»
jnthn m: my $a = 42; say (($a =:= $a) // ($a.WHAT =:= $a.WHAT))
camelia rakudo-moar fe2be6: OUTPUT«True␤»
lizmat indeed, this shows up from optimize=2
jnthn m: my $a = 42; say nqp::unless($a =:= $a, $a.WHAT =:= $a.WHAT) 16:06
camelia rakudo-moar fe2be6: OUTPUT«===SORRY!=== Error while compiling /tmp/Nz3XOBwIVX␤Could not find nqp::unless, did you forget 'use nqp;' ?␤at /tmp/Nz3XOBwIVX:1␤------> ::unless($a =:= $a, $a.WHAT =:= $a.WHAT)⏏<EOL>␤»
jnthn m: use nqp; my $a = 42; say nqp::unless($a =:= $a, $a.WHAT =:= $a.WHAT)
camelia rakudo-moar fe2be6: OUTPUT«1␤»
lizmat $ perl6 --optimize=1 -e 'my $a = 42; say $a =:= $a || $a.WHAT =:= $a.WHAT'
True
$ perl6 --optimize=2 -e 'my $a = 42; say $a =:= $a || $a.WHAT =:= $a.WHAT'
1
jnthn Well, that isolates it a good bit, then :)
lizmat rakudobug it ?
jnthn yeah
lizmat ok, will do
jnthn I wonder if it's elimiating a nqp::p6bool thinking it's not needed
lizmat around line 1250 in Optimizer seems to be applicable 16:08
way over my head, though...
jnthn Wonder if it'll need mine :) 16:11
16:11 mops joined
lizmat rt.perl.org/Ticket/Display.html?id=127951 16:13
nine_ a bit shorter: perl6 --optimize=2 -e 'my $a = 42; say $a =:= $a || True' 16:21
dalek kudo/nom: 463e758 | lizmat++ | src/core/ (13 files):
Streamline infix:<eqv>

See also irclog.perlgeek.de/perl6/2016-04-19#i_12363756		 16:28
nine_ lizmat: why is this faster? github.com/rakudo/rakudo/commit/46...b410dbR763 16:31
lizmat admits to not closely benchmarking that one :-) 16:33
nine_ The MAST suggests that we actually do call multi sub infix:<=:=>(Mu \a, Mu \b) for the =:= 16:39
jnthn: but I guess this ^^^ would be inlined if hit a couple of times?
jnthn nine_: Eventually 16:43
nine_: But not one time
I mean, the code that it's in lined into (so, calling it) would have to be run many times
It may be the "static" inlining
nine_ Makes me wonder if such optimizations are really worth making rakudo's code less approachable to ordinary Perl 6 users. 16:44
lizmat nine_: the new Bool:D eqv is about 10% faster 16:45
nine_: for the case where there's a difference in the last byte of two Blobs
nine_ lizmat: I guess what I mean is that I'd love our compile and runtime optimizers to be smart enough so that such manual optimizations are no longer needed and we can keep Perl 6 written mostly in Perl 6 :) 16:47
lizmat nine: in that particular case, the optimizer would have to have been pretty smart 16:48
nine_: as I just didn't think straight when writing the ternary version 16:49
as soon as you see True or False in a ternary, there's something wrong (usually)
nine_ That's....True ;) 16:50
In this particular case, I'd actually say that the new version is more readable :)
lizmat brb
17:04 awwaiid joined
[TuxCM] This is Rakudo version 2016.04-4-gfe2be65 built on MoarVM version 2016.04 17:05
test 22.735
test-t 12.632
csv-parser 26.696
rakudobrew build moar-blead
17:09 dalek joined 17:14 geekosaur joined
lizmat is there a reason we don't have an IO::Handle.printf ? 17:16
17:19 [TuxCM] joined
dalek ast: 39e0550 | lizmat++ | S32-list/c (2 files):
Handle more paranoid infix:<eqv> of 463e7589a1c332
 17:28
ast/6.c-errata: ae3ad50 | lizmat++ | S32-list/c (2 files):
Handle more paranoid infix:<eqv> of 463e7589a1c332
17:33 mops left
lizmat food& 17:43
17:44 lizmat joined
timotimo anyone got a clever idea how we could make our division routines aware of "i know the RHS isn't zero" so we can make the division simpler? currently it has the "fail" in it, and i expect it doesn't get inlined where it could be 18:11
18:46 sno joined 19:46 sno joined 20:00 brrt joined
brrt .tell jnthn: I suggest disabling the JIT by default on the reframe branch 20:05
that at least would make it mergeable until i've fixed the JIT 20:06
jnthn Heh, no tell bot here 20:10
brrt: If you're reading: it's no hurry, that branch is not for merge until after part 2 of the refactors I'm doing anyway. :) 20:11
teatime will be back tomorrowish. 20:55
21:32 sno joined 21:47 sortiz joined 22:14 vendethiel joined 22:59 vendethiel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!