Zoffix m: my $recipe = Mix.new(butter => 0.22, sugar => 0.1, flour => 0.275, sugar => 0.02); dd $recipe 00:21
camelia rakudo-moar e411e5: OUTPUT«Mix $recipe = ().Mix␤»
Zoffix m: my $recipe = mix(butter => 0.22, sugar => 0.1, flour => 0.275, sugar => 0.02); dd $recipe
camelia rakudo-moar e411e5: OUTPUT«Unexpected named parameter 'butter' passed␤ in block <unit> at <tmp> line 1␤␤»
Zoffix This looks at best LTA.
The docs are particularly confusing: 00:22
m: my $n = mix "a", "a", "b" => 0, "c" => 3.14;; dd $n
camelia rakudo-moar e411e5: OUTPUT«Mix $n = ("a"=>2,:c(3.14)=>1,:b(0)=>1).Mix␤»
Zoffix Normally, I'd want to use weights, not store Pair objects
I wonder if someone just documented the behaviour instead of realizing it's a bug. 00:24
timotimo m: my $recipe = (butter => 0.22, sugar => 0.1, flour => 0.275, sugar => 0.02).Mix; dd $recipe 00:30
camelia rakudo-moar e411e5: OUTPUT«Mix $recipe = ("flour"=>0.275,"butter"=>0.22,"sugar"=>0.12).Mix␤»
Zoffix timotimo, but is .new and mix() supposed to have such behaviour, which IMO is broken.
m: dd ($(<a b c>) => 2.5).Mix 00:31
camelia rakudo-moar e411e5: OUTPUT«(("a", "b", "c")=>2.5).Mix␤»
timotimo i think mix is supposed to behave like set does
Zoffix m: say ($(<a b c>) => 2.5).Mix
camelia rakudo-moar e411e5: OUTPUT«mix((a b c)(2.5))␤»
timotimo m: say mix(<a b a a b a b b c c d d d d d d e e>) 00:32
camelia rakudo-moar e411e5: OUTPUT«mix(a(4), c(2), b(4), e(2), d(6))␤»
timotimo m: say set(<a b a a b a b b c c d d d d d d e e>)
camelia rakudo-moar e411e5: OUTPUT«set(a, c, b, e, d)␤»
Zoffix Considering a Mix has Real weights, the behavious of mix is nearly useless.
But you have have Pair objects as keys! 👏 00:33
timotimo true, there's an infinite amount of values you cannot get with mix 00:34
so ... use Mix for those?
dalek ast: 1efb4d5 | (Zoffix Znet)++ | S02-types/set.t:
Set.hash does not cause keys to be stringified

RT#127402		 01:30
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127402
jdv79 i think i have a supply block blocking 01:31
had a few week old rakudo. building new now.
is that a known thing?
gfldex jdv79: one blocking bug was fixed the other week (there may be more) 01:32
geekosaur several things of that sort were recently found and fixed
jdv79 ok
dalek ast: 513a946 | (Zoffix Znet)++ | S02-types/set.t:
Avoid spurious redeclaration warning
 01:33
ast: b3dfe18 | (Zoffix Znet)++ | S02-types/sethash.t:
SetHash.hash does not cause keys to be stringified
 01:35
jdv79 hmm. no joy. i seem to be hard up on a futex. 01:41
dalek ast: f434b81 | (Zoffix Znet)++ | S02-types/ (4 files):
[TODO FUDGE] .hash does not stringify keys on [Bag|Mix][Hash]?

RT#127402		 01:46
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127402
jdv79 supply {} seems fickle 01:48
Zoffix If you're calling done() on the first time the block enters,. it's a known blocking bug 01:51
jdv79 nope. just assigning the supply to a var and returning that and then whenever'ing on it 01:57
returning the supply directly to the whenever seems to work
Zoffix Passing TODOs in substest() do not get announced as passing todos :( 02:11
dalek kudo/nom: f1313db | (Zoffix Znet)++ | src/core/Baggy.pm:
.hash on [Bag|Mix][Hash]? types must not stringify keys

Fixes RT#128806		 02:18
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128806
Zoffix Well, that was much easier than I thought it'd be. 02:19
dalek ast: 874986f | (Zoffix Znet)++ | S02-types/ (4 files):
Unfudge now passing tests
ShimmerFairy I do wish the :rotate adverb existed on the shift operators. Or that I could do this: 02:41
m: multi sub infix:«+<»($a, $b, :$rotate!) { "ALIVE" }; say 1 +< 3; say 1 +< 3 :rotate; 02:42
camelia rakudo-moar f1313d: OUTPUT«8␤Unexpected named parameter 'rotate' passed␤ in block <unit> at <tmp> line 1␤␤»
ShimmerFairy thinks the :rotate adverb would need to take an argument though, at least for bigints, e.g. :rotate(32)
gfldex i believe to remember that bitwise shift was left simple to allow direct mappings to machine code 02:43
ShimmerFairy gfldex: still could, with the method I tried above (a multi with an explicit :rotate adverb) 02:44
m: multi sub infix:«+<<»($a, $b, UInt :$rotate!) { ($a +< $b % 2**$rotate) +| ($a +> ($rotate - $b)) }; say (0xFE +<< 1 :rotate(8)).base(16) # an example of what I'm thinking 02:48
camelia rakudo-moar f1313d: OUTPUT«FD␤»
travis-ci Rakudo build errored. Zoffix Znet '.hash on [Bag|Mix][Hash]? types must not stringify keys 03:13
travis-ci.org/rakudo/rakudo/builds/149070512 github.com/rakudo/rakudo/compare/e...313dbc93dd
buggable travis-ci, one build failed but NOT due to the timeout.
Zoffix Interesting. My bot spotted an inconsistency in travis jobs reports. My original working code had 'no output' and now it changed to 'No output' 03:15
travis-ci.org/rakudo/rakudo/builds/149070512 03:22
buggable Zoffix, one build failed but NOT due to the timeout.
Zoffix travis-ci.org/rakudo/rakudo/builds/149070512 03:23
buggable Zoffix, one build failed due to the timeout. No other failures.
Zoffix m: use Test; my @results; lives-ok { class R { method foo { @results.push: 'meow'}} R.new.foo }; dd @results 03:26
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Cannot reverse the args of . because dotty infix operators are too fiddly␤at <tmp>:1␤------> method foo { @results.push: 'meow'}} R.⏏new.foo }; dd @results␤»
dalek ast: bc156fa | (Zoffix Znet)++ | S12-subset/subtypes.t:
Remove trailing whitespace
 03:27
ast: b00a4f4 | (Zoffix Znet)++ | S12-subset/subtypes.t:
:D on subset corretly works in multi dispatch

RT#127367		 03:28
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127367
ShimmerFairy I've run into an absolutely weird bug where apparently some of my role-required methods aren't accepted as fulfilling that requirement if they have a hyphen in the name O.o . And I can't figure out the root issue. (And it's not a precomp issue.) 04:08
TimToady yeah, that's weird 04:14
geekosaur we had a few cases earlier where something was working by name instead of with the actual Role, didn't we? 04:15
(which broke when the name handling turned out to be Wrong)
TimToady I wonder if it could actually be a rope failure 04:17
since hyphenated names have to be glued together at some point 04:18
trying with underscores might be informative 04:19
ShimmerFairy TimToady: I thought so at first, but after going through the three dashed methods that cause an error, it just errors on one of those three methods again. So I don't think it's the hyphen that does it, fixing it in one just "delays" its error. 04:20
trying foo'bar or foobar doesn't work either. I'm updating my rakudo right now just to make sure it applies in the latest version. 04:21
TimToady huh, sounds more like a buffer boundary error 04:23
or possibly memory corruption or jit damage 04:24
maybe try turning off spesh/jit
ShimmerFairy ok, I'll try that after I'm done updating. Is it an environment variable that turns it off? 04:25
TimToady MVM_SPESH_DISABLE turns off all dynamic opts; there are other more specific ones 04:26
ShimmerFairy still happens with MVM_SPESH_DISABLE=1 perl6 ... 04:30
TimToady then it's not that 04:31
ShimmerFairy TimToady: I just figured it out, and the answer is still insane: 04:34
m: #|(abc) role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'foo' must be implemented by A because it is required by a role␤at <tmp>:1␤»
ShimmerFairy m: #|abc␤role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo
camelia rakudo-moar f1313d: OUTPUT«OK␤»
ShimmerFairy m: #|[[[abc]]]␤role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'foo' must be implemented by A because it is required by a role␤at <tmp>:2␤»
ShimmerFairy TimToady: apparently, attaching a multi-line declarator block to the role breaks it. ~somehow~ 04:35
TimToady huh
m: #|(abc)␤#|xyz␤role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo 04:36
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'foo' must be implemented by A because it is required by a role␤at <tmp>:3␤»
ShimmerFairy m: role A { method foo { ... } }; #=(abc) class B does A { method foo { "OK" } }; say B.foo # doesn't break with _trailing_ declarator block, though
camelia rakudo-moar f1313d: OUTPUT«OK␤»
TimToady m: #|(abc␤)#|xyz␤role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo 04:37
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'foo' must be implemented by A because it is required by a role␤at <tmp>:3␤»
TimToady m: #|(abc␤)#|xyz␤#comment␤role A { method foo { ... } }; class B does A { method foo { "OK" } }; say B.foo 04:38
camelia rakudo-moar f1313d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Method 'foo' must be implemented by A because it is required by a role␤at <tmp>:4␤»
TimToady yeah, that's pretty crazy 04:39
ShimmerFairy rakudobugs
Got it down as #128810 04:45
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128810
TimToady so, um, why does "git describe" in nqp say "parrot-42-g9073af7" now? 05:51
ShimmerFairy TimToady: apparently because there's a "parrot" tag. 05:54
geekosaur there's a recent branch to remove the last of the parrot support iirc. but that sounds like the wrong branch name and if it's an annotated tag, it was unfortunately named... 05:56
TimToady is in branch master
geekosaur ...and when I poke at a just-updated rakudobrew triple, git describe in nqp tells me 2016.04-14-gd54d719 05:58
ShimmerFairy TimToady: looks like a tag was added to the last parrot-having commit. Seems to me like it should've been a lightweight tag, since git describe would skip that by default.
TimToady is testing a patch for non-associative vs non-list-associative messages, but it involves changing both nqp and rakudo 06:01
geekosaur oh, wrong tree, there's two of them...
ShimmerFairy if it's possible and not history-destroying, I'd try to delete that tag and put a lightweight one in its place.
geekosaur shouldn't be history-destroying, but the tag description seems useful. unless you rename the tag to end-of-parrot or something 06:02
TimToady if I put my patch in, you could tag my patch with the normal 2016 etc, I suppose 06:03
geekosaur well, technically it is jhistory-destroying because it has already gone out to other sites. practically, the tag is not there to be used, so it "should" be okay
dalek kudo/nom: f568db2 | TimToady++ | src/ (2 files):
distinguish nonlistassoc from nonassoc
 06:04
p: 9073af7 | TimToady++ | src/HLL/Grammar.nqp:
split nonassoc error into list vs non-list forms
TimToady there, now that rakudo will work better with that nqp, however we decide to describe it...
ShimmerFairy One approach might be to make a properly lightweight tag called "ex-parrot" or something, and then let people know they might have to delete the "parrot" tag. (Or just live with it, since it'll be back to normal after the next release.) 06:07
TimToady you could tag my patched version with 2016-07-02 or so, I guess 06:08
TimToady is not a tag expert, and the checked in rakudo will work okay without the new nqp 06:09
it'll just give the nonassoc message where you'd want the nonlistassoc message
ShimmerFairy I don't have a commitbit at the moment I believe, so I can't be the one to do it right now :P
TimToady doesn't really want to learn about tags tonight... 06:12
m: 1 Z 2 X 3
camelia rakudo-moar f568db: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Operators 'Z' and 'X' are non-associative and require parentheses␤at <tmp>:1␤------> 1 Z 2 X⏏ 3␤ expecting any of:␤ infix␤ infix stopper␤»
TimToady that'll just give the more generic message till we bump the nqp rev, anyway 06:13
(the reason nqp decides which message is because that's where EXPR lives) 06:19
[Tux] RT#128184 still fails 06:43
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128184
[Tux] This is Rakudo version 2016.07.1-104-gf568db2 built on MoarVM version 2016.07-13-gcba3ae3 06:45
test 15.639
test-t 8.429
csv-parser 16.895
travis-ci Rakudo build errored. TimToady 'distinguish nonlistassoc from nonassoc' 06:58
travis-ci.org/rakudo/rakudo/builds/149094024 github.com/rakudo/rakudo/compare/f...68db26f859
buggable travis-ci, one build failed due to the timeout. No other failures. 06:59
dalek p: f5ac9c4 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/jast2bc/JASTCompiler.java:
Add support for LDC opcode.

We had half of this already and it proved useful for debugging.		 07:49
psch j: A: for ^1 { B: for ^1 { last A } } 07:50
camelia ( no output )
psch j: A: for ^1 { B: for ^1 { last A } }
camelia rakudo-jvm cd19db: OUTPUT«===SORRY!===␤labeled last without loop construct␤» 07:51
psch j: A: for ^1 { FIRST {}; B: for ^1 { last A } }
camelia ( no output )
psch the second one installs two different handlers
both of which handle a cat mask of 28, which is next/last/redo
well, "second one" here meaning "the one with the phaser" 07:52
the unphasered only installs one handler with cat mask 28, and it has the same id as the second one that the phasered example installs
so i'm guessing we somehow don't actually install a handler in nqp::handle if we nest two blocks that only differ in their label but are otherwise similar enough..? 07:54
it does seem weird that we swallow the *outer* handler though
i mean, even more weird
github.com/perl6/nqp/blob/master/s....nqp#L4886 08:27
$handler_cares is 1 for labeled handlers, 0 for unlabeled ones 08:28
the minimal test cases work with turning the unless into an if
...this is probably the least longest time debugging for the least amount of changed code that i've had on rakudo up to now :S 08:29
s:1st/least//
roast++ 11:00
'cause even though it's slow i now learned my fix breaks lots of other things vOv 11:01
like for example a labeled CX where the label is on the block that throws... 11:02
arnsholt Roast is indeed a lifesaver 11:03
Found some absolutely stupid bugs in the Rakudo side of my better-O refactor 11:04
lizmat commute to Amsterdam.PM meeting& 12:06
arnsholt Could someone do me a favour and review the better-O branches in NQP and Rakudo? 13:02
It touches the grammar/parsing internals (but only lightly), and there should be no functional changes beyond the change in API to HLL::Grammar.O() 13:04
masak does so 13:06
arnsholt Cheers! 13:08
masak arnsholt: wow, it looks like a clear net improvement 13:10
love how much parsing code went away on the NQP end 13:11
and on the Perl 6 end it just looks like we use named params better
arnsholt Yeah, I remember reading the original HLL::Grammar.O and basically going ewwwwwwwww 13:14
masak :)
arnsholt My original attempt at fixing it (two years ago, according to GH. Wow.) foundered for some reason, but this time it worked out fine 13:15
masak arnsholt: my one question is, though -- if this is part of Perl 6's API in some sense, what does that mean in terms of deprecation cycle?
arnsholt It's not really part of the Perl 6 API
A grammar Foo doesn't inherit from HLL::Grammar, but any Perl 6 code that does low-level enough monkeying around to inherit from it *would* of course be impacted 13:16
masak I think you're right, but only because no-one does cool stuff with extending Perl 6's own grammar yet
arnsholt Yeah 13:17
Only significant slang I can think of is Tuxic, but from a grep of the source on GH it doesn't look like it uses O() 13:18
masak ok, good 13:19
seems we agree that it's not part of the API *because no-one uses it*
arnsholt (Oh, and speaking of HLL::Grammar.O, I'm pretty sure it's basically unchanged since pmichaud++'s PGE)
Yeah, more or less
So I guess merge, but try to give ample room before a release in case the Emmentaler turns up a user after all? 13:20
masak sounds good to me 13:21
maybe also check with a core dev about the deprecation stuff 13:22
I'm just a tourist, not a core dev ;)
pmurias arnsholt: why do you use the :inherit key as opposed to doing it the way the previous attempt did? 13:23
arnsholt pmurias: Because it makes the positional argument ambiguous. Do you want to inherit from the named hash, or save to it? 13:24
So I decided to keep the positional purely for saving, and doing all the precedence-related stuff using nameds 13:25
Hmm, looking at the release schedule the next one is in about two and a half weeks (20/8), so I'll leave the branch for now and merge it after the release is cut 13:29
pmurias: irclog.perlgeek.de/perl6-dev/2016-0...i_12954360 (missed that you disconnected) 13:30
[Coke] we need smoke-me branches. 13:31
ah, we have 'em.
if your branch starts with /smoke-me/ , travis will run it to make sure it's ok.
arnsholt Does that test against an extended test suite, or just roast? 13:32
pmurias arnsholt: what is the benefit of <O(:inherit<%tight_or>, :op<unless>)> over <O(|%tight_or, :op<unless>)> 13:34
?
[Coke] arnsholt: maybe not even roast, I don't know.
at least 'make test'. :)
arnsholt pmurias: Nothing really, except that the %tight_or variable doesn't exist 13:35
We could always extract those into variables, but then they'd be private to the NQP/Rakudo grammar rather than shared of course 13:36
pmurias arnsholt: I found your old ticket about <O(|%tight_or, :op<unless>)> not working in the old times 13:39
arnsholt: do we want that to be shared? 13:41
arnsholt I have no idea, TBH. Maybe? 13:42
pmurias seems like a bug
arnsholt jnthn: Do you have an opinion on this?
pmurias having .O calls in Snake::Grammar override stuff in the Rakudo one doesn't seem very desired 13:43
arnsholt Ooh, yeah. That's bad
jnthn I think we want to go the <O(|%tight_or, ...)> way
If we want to expose the precedence defaults, that can be done through a method on Perl6::Grammar or so 13:44
arnsholt Yeah, that sounds way more reasonable
jnthn Slangs may want that
arnsholt Yeah, probably 13:45
jnthn Though it's not a blocker for them if we don't expose it, they'd just have to spell out all the things.
arnsholt But exposing those hashes through accessor methods sounds way saner than random grammars overwriting each other
jnthn Indeed
arnsholt But then I'll hack up another pair of commits that kills off :inherit and $save and moves the saved stuff into local hashes in the grammars 13:46
Thanks for the review guys!
pmurias wrote tests and closed the old ticket that was blocking <O(|%tight_or, ...)> back in the day 13:49
arnsholt Does it work these days? 13:51
Looking at that ticket, I remember talking with jnthn about it at some point (which is really helpful, given the bug is *four years* old) where it turns out it's not really supposed to work, IIRC
The flattening is a purely syntactic operation in NQP, so only something %-sigilled will get flattened as nameds; anything else is flattened positionally 13:52
dalek p: b2c8d01 | (Pawel Murias)++ | t/nqp/031-grammar.t:
Test that flattening into name arguments works from withing rules.
pmurias arnsholt: <O(|%tight_or)> works <O(|$tight_or_with_wrong_sigil)> doesn't work 13:54
arnsholt: I assume the latter won't be fixed
arnsholt Yeah, there's even a closed ticket about it!
#146
I suspect that's what #46 was running into too 13:56
So. The original O() was 81 lines of code. After killing off the :inherit stuff, it's 10 =D 14:10
jnthn \o/
dalek kudo/nom: 8099135 | (Zoffix Znet)++ | docs/release_guide.pod:
Add missing space in command
 14:26
[Coke] vsavkin.com/typescript-how-to-be-s...eb08485fe6 Js type safety with TypeScript 14:29
dalek kudo/nom: 3c2849c | (Zoffix Znet)++ | docs/release_guide.pod:
Mention public GPG keys tags are signed with need to be added to GitHub
 14:31
p: 1bef250 | (Zoffix Znet)++ | docs/release_guide.pod:
Add missing space in command
 14:32
[Coke] Zoffix: thanks for the GPG notice. I just added my key and now github.com/rakudo/rakudo/releases/tag/2016.03 is (e.g.) Verified 14:34
dalek p: d1652cd | (Zoffix Znet)++ | docs/release_guide.pod:
Mention GPG keys need to be added to GitHub
timotimo buggable: rt 15:11
hm, is that the right one?
buggable timotimo, TOTAL: 1355, UNTAGGED: 611, BUG: 414, LTA: 90, JVM: 62, NYI: 32, SEGV: 28, UNI: 25, RFC: 24, PERF: 19, POD: 14, CONC: 11, @LARRY: 10, TODO: 9, PRECOMP: 8, GLR: 6, BUILD: 5, STAR: 4, WEIRD: 3, LTA ERROR: 3, MOARVM: 2, OSX: 2, FEATURE REQUEST: 1, CPP: 1, SPEC: 1, LIST: 1, LHF: 1, SPESH: 1, DOCS: 1, NATIVECALL: 1 Details: bug.perl6.party/1470150706.html
[Coke] Zoffix: your [UNTAGGED] logic is faulty; picking up, e.g. RT#124522[UNTAGGED] Roast rakudo skip/todo test:./S05-metasyntax/angle-brackets.t line:122 reason: 'colon arguments [NYI]' 15:23
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124522
travis-ci Rakudo build passed. Zoffix Znet 'Add missing space in command' 15:28
travis-ci.org/rakudo/rakudo/builds/149202203 github.com/rakudo/rakudo/compare/f...991357d2a5
unmatched} .seen FROGGZ 15:37
yoleaux2 I haven't seen FROGGZ around.
unmatched} .seen FROGGZ_
yoleaux2 I haven't seen FROGGZ_ around.
hoelzro .seen FROGGS 15:38
yoleaux2 I saw FROGGS 31 Jul 2016 11:22Z in #perl6-dev: <FROGGS> I was looking in their tests and documentation and even asked in their irc channel but got no answer in how to combine stderr and stdout
TimToady jnthn: do you have any prefers as to which way to go with nqp's current 'git describe'?
TimToady is hesitant to bump when the version says parrot-46-gd1652cd 15:39
jnthn TimToady: Seems it'll right itself in a couple of weeks on the next release... For now I'd just git describe --match 2* 15:40
unmatched} hoelzro: are you able to upload your GPG public key to your GitHub account so the 2016.05 tag shows as verified? github.com/rakudo/rakudo/tags gpg --armor --export <email> to generate public key and then add it on github.com/settings/keys
jnthn To only match agaisnt one of the release tags
TimToady that'll work for the bump then?
hoelzro unmatched}: sure; I don't have the key here, I'll do it after work
unmatched} .ask FROGGS are you able to upload your GPG public key to your GitHub account so the 2016.06 tag shows as verified? github.com/rakudo/rakudo/tags Just run gpg --armor --export <email> to generate public key and then add it on github.com/settings/keys
yoleaux2 unmatched}: I'll pass your message to FROGGS.
unmatched} hoelzro: thanks 15:41
jnthn TimToady: Should do 15:44
Should give you something like 2016.07-g.... 15:45
dalek kudo/nom: e1c7722 | TimToady++ | tools/build/NQP_REVISION:
bump npq to get nonlistassoc fix

Fixes RT #128811. There is a new X::Syntax::NonListAssociative exception that is derived from X::Syntax::NonAssociative.		 16:01
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128811
timotimo not perl, quite. 16:02
psch well, it wasn't the -2 +6 character fix for the label stuff 16:03
and there's more hints that it's actually really, really weird
j: A: for ^2 -> $, $ { B: for ^1 { last A } }
camelia ( no output )
psch apparently it works as long as we don't use the same SlippyIterator does'er between the two iterators 16:04
'cause one-phasered-the-other-not works, different arity (one-1ary-one-2ary, one-2ary-one-3ary and so on) works 16:05
j: A: for ^1 { FIRST { }; B: for ^1 { FIRST { }; last A } } 16:06
camelia rakudo-jvm cd19db: OUTPUT«===SORRY!===␤labeled last without loop construct␤»
psch but both phasered also doesn't work
travis-ci Rakudo build passed. Zoffix Znet 'Mention public GPG keys tags are signed with need to be added to GitHub' 16:07
travis-ci.org/rakudo/rakudo/builds/149203877 github.com/rakudo/rakudo/compare/8...2849ca7bfa
[Coke] Zoffix: your RT reports on [LTA ERROR] - mine treated that the same as [LTA] and [ERROR] - for now I will update those tickets to be "[LTA] Error" instead. 16:09
unmatched} buggable: rt 16:11
buggable unmatched}, TOTAL: 1364, UNTAGGED: 615, BUG: 417, LTA: 91, JVM: 62, NYI: 32, SEGV: 28, RFC: 25, UNI: 25, PERF: 19, POD: 14, CONC: 11, @LARRY: 10, TODO: 9, PRECOMP: 8, GLR: 6, BUILD: 5, STAR: 4, WEIRD: 3, LTA ERROR: 3, MOARVM: 2, OSX: 2, FEATURE REQUEST: 1, CPP: 1, SPEC: 1, LIST: 1, LHF: 1, SPESH: 1, DOCS: 1, NATIVECALL: 1 Details: bug.perl6.party/1470154316.html
TimToady m: 1 X 2 Z 3
camelia rakudo-moar e1c772: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Only identical operators may be list associative; since 'X' and 'Z' differ, they are non-associative and you need to clarify with parentheses␤at <tmp>:1␤------> 1 X 2 Z⏏ 3␤ expecting any o…»
TimToady m: 1 cmp 2 leg 3 16:12
camelia rakudo-moar e1c772: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Operators 'cmp' and 'leg' are non-associative and require parentheses␤at <tmp>:1␤------> 1 cmp 2⏏ leg 3␤ expecting any of:␤ infix␤ infix stopper␤»
unmatched} [Coke]: yeah, it basically just reports the [] tags verbatim. I think rather than special-casing, admins should change titles of tickets that don't use a common tag. Like that FEATURE REQUEST one should be RFC.
TimToady let me just veryify, if I change roast/master, that's proto 6.d, not 6.c errata, correct? 16:13
unmatched} BTW, I fixed the bug where your nick wasn't being registered with buggable
buggable: rt FEATURE REQUEST
buggable unmatched}, Found 1 ticket tagged with FEATURE REQUEST. Details: bug.perl6.party/1470154400.html
unmatched} TimToady: correct 16:15
6.c-errata is the branch for 6.c errata
dalek ast: 5939e74 | TimToady++ | S03-operators/precedence.t:
test difference betwen nonassoc and nonlistassoc

also, check precedence level of structural infix		 16:42
TimToady (the old tests will work with the new exceptions because X::Syntax::NonListAssociative is derived from X::Syntax::NonAssociative) 16:46
[TuxCM] This is Rakudo version 2016.07.1-107-ge1c7722 built on MoarVM version 2016.07-13-gcba3ae3 17:28
test 15.216
test-t 8.160
csv-parser 17.262
[Coke] added [BOOTSTRAP] to some tickets where nqp is leaking into rakudo 17:37
someone want to suggest a tag for "numbers not numbering numerically" ? 17:38
(happy to leave them as [BUG] for now)
TimToady: is rt.perl.org/Ticket/Display.html?id=77474 still an issue for you? 17:39
TimToady well, I'd still like to allow recursive definitions like that 17:48
[Coke] hokay. 18:03
dalek kudo/nom: cc3932d | lizmat++ | src/core/Hash.pm:
Make Hash[Any].new.perl roundtrip as well
 18:11
masak oh! they're now two exceptions because the messages are different 19:52
for a while there I hallucinated a whole new associativity type, and it made me scared and confused :>
lizmat decommute& 20:17
[Coke] for windows, we need to recommend a file extension that isn't .pl; .p6? or .pl6? 20:27
gfldex .pl collides with perl5 (no shebang), bot .p6 and .pl6 are not used by a default installation 20:29
that's for win8, let me check on win10
same for win10 20:31
.p6 is shorter and short is sexy (disclaimer: i'm not tall)
[Coke] github.com/perl6/doc/issues/778 if anyone cares to comment. 20:35
dalek Heuristic branch merge: pushed 39 commits to rakudo/better-O by arnsholt 21:46
p/better-O: 000ba5b | arnsholt++ | src/ (2 files):
Remove HLL::Grammar.O(:inherit).

This functionality is removed in favour of lexical hashes flattened directly into invocations of <O(...)>.
p: e4f47ee | Xliff++ | docs/ops.markdown:
Proposed documentation for nqp::nativecallrefresh

After discussion in #perl6.		 21:51
p: d3e3707 | Xliff++ | docs/ops.markdown:
Wording change.
p: 6aeea36 | Xliff++ | docs/ops.markdown:
Typo fixed.
p: a3e9ef3 | peschwa++ | docs/ops.markdown:
Merge pull request #302 from Xliff/patch-1

99aa515 | (Zoffix Znet)++ | docs/ops.markdown: Remove spurious bullet
Zoffix m: say Date.today - Date.new('2016-05-06') 22:10
camelia rakudo-moar cc3932: OUTPUT«89␤»
Zoffix mst, 89 days! A new record :)
Zoffix chugs a beer
timotimo record for what? 22:16
Zoffix timotimo, being sober
timotimo oh 22:17
Zoffix :)
TimToady m: for (@a xx 1) {} 22:33
camelia rakudo-moar cc3932: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Variable '@a' is not declared␤at <tmp>:1␤------> for (⏏@a xx 1) {}␤»
TimToady m: my @a; for (@a xx 1) {}
camelia rakudo-moar cc3932: OUTPUT«WARNINGS for <tmp>:␤Useless use of @a in sink context (line 1)␤»
TimToady that warns for a rather strange reason, turns out
it's calling EXPR twice on the @a xx 1
the first time is in the lookahead for detecting the C/p5-ism: for ($i = 1; $i; ++$i) {} 22:34
and that's the codegen that is carping, not the actual parsing of the for loop
so it really is a useless use of @a, in a way 22:35
it's even failing the lookahead, since there's no ';' inside, but that's enough for EXPR to codegen the closure that will turn out to be useless 22:36
timotimo hah, that's amusing 22:38
also probably kind of expensive, wouldn't it be?
TimToady only if you actually use parens on your for 22:39
timotimo ah
Zoffix m: my @a; for @a xx 1 {}
camelia ( no output )
timotimo you're not supposed to :)
TimToady I'm thinking maybe we shouldn't parse that lookahead using EXPR, or should find some way of disabling codegen inside <?before> 22:40
well, astgen 22:41
usually, an ast will get attached to the Match, and just thrown away, but this apparently stows something away within $*W when you thunkify the xx 22:42
m: say (my $i = 1; $i; ++$i).perl 22:43
camelia rakudo-moar cc3932: OUTPUT«(2, 2, 2)␤»
TimToady maybe we should detect (;;) at a semantic level sometime after the for args are parsed (but only parsed once) 22:44
timotimo potentially doable
TimToady m: say (my $i = 1; $i; ++$i).WHAT
camelia rakudo-moar cc3932: OUTPUT«(List)␤»
TimToady well, if we don't throw away the info
m: say (;;).WHAT 22:45
camelia rakudo-moar cc3932: OUTPUT«(List)␤»
TimToady otoh, maybe this is a more general problem with <?before> that we need to think about
otgh, when we talk about lookaheads, we often say not to do anything with side effects that can't be undone... 22:47
and we did that here :)
timotimo we're just a bunch of dum-dums 22:54
hoelzro unmatched}: I tried to add my GPG key, but I get "keyring packet should only contain a single entity" 23:13
oh, got it 23:15
I forgot I made a new key last fall =/
hmm, is it a problem that my old key was used to sign 2015.06? 23:17
TimToady well, it appears I can fix the general case by slowing down parsing by 7% or so :( 23:34
that is, if put 'my $*SUPPOSING = 1;' inside <?before>, and look at it inside make_thunk_ref to disable the side effect, that's how much overhead there is in the dynvar 23:35
about 2/3 of that overhead is just setting the dynvar inside <?before> because that's such a common rule 23:36
some of that overhead is contention for our limited dynvar cache 23:37
it's possible that setting a dynvar in method before is also disabling some inlining/speshing
I don't know how much our proposed new dynvar cache would offset all that 23:38
timotimo oof
TimToady also, my timings are not entirely scientific
I did suspend firefox at least :) 23:39
timotimo :)
TimToady and I attempted to let my CPU cool down before each parse run
unmatched} hoelzro: nah, I don't think releases pre-Christmas matter that much any more. 23:40

Powered by Cro and the Raku® Programming Language.

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

Thank you!