gfldex m: (1,'A').grep(* eqv 1) 00:40
camelia ( no output )
gfldex m: dd (1,'A').grep(* eqv 1)
camelia rakudo-moar aa5e49: OUTPUT«(1,).Seq␤»
psch okay hm 09:33
j: A: for ^1 { B: for ^1 { last A } } # this one still
camelia rakudo-jvm cd19db: OUTPUT«===SORRY!===␤labeled last without loop construct␤»
psch the notable thing i found out just now is
that outwards from the &next call there's two CallFrames that have a !HANDLER__\d+ lexical 09:34
one is the &next itself, afaict
and the other is four .callers away from it
of note there is, that the CallFrame with the lexical 'B' - i.e. the inner label - is one caller lower, so three .callers from the &next callframe 09:35
but both those lexical handlers have the same id 09:38
so we clearly are in the same handler and it can't be the right one..?
i'm not really sure what exactly any of this means :S
hrm, what's my jvm equivalent of '(MVMuint64)(f->work[fh->label_reg].o)'? :) 09:41
ShimmerFairy
.oO(probably involves something named MoarVirtualMachineUnsignedInteger64Bits)
10:02
jnthn heh :) 10:07
On JVM it'd probably have to be stored in a lexical rather than a normal local
'cus Java locals are ont he stack and inaccessible from "outside"
psch hm, not sure how i'd guarantee that the name i found is in fact a label..? 10:19
arnsholt jnthn: Digging in NQP, I notice that the ident subrule is implemented in Cursor, not HLL::Grammar. Is this purely for speed reasons, or is there a deeper reason to it? 11:07
dalek kudo/nom: f3afe43 | (Steve Mynott)++ | INSTALL.txt:
Configure.pl now needs at least perl 5.10
11:11
kudo/nom: 1751f1e | lizmat++ | INSTALL.txt:
Merge pull request #833 from stmuk/nom

Configure.pl now needs at least perl 5.10
jnthn arnsholt: It's a Perl 6 built-in :) 11:17
arnsholt: Like print, lower, upper, etc.
So it's in there so you can use it in normal regexes/grammars 11:18
arnsholt Ah, right 11:32
Thanks!
dalek p: 377c365 | lizmat++ | tools/build/MOAR_REVISION:
Bump NQP to get latest async fixes from MoarVM
12:39
kudo/nom: 02b2e30 | lizmat++ | tools/build/NQP_REVISION:
Bump NQP to get the latest MoarVM async improvements

Feels odd to push a revision with "parrot" in it, though :)
12:57
star: 612110d | (Hinrik Örn Sigurðsson)++ | tools/build/module-install.pl: 12:59
star: Panda: Don't try to resolve depencies
star:
star: Without this, Panda tries to access the network to resolve the deps for
star: some modules (16 out of 32 at the moment), leading to them getting
[Coke] which change drove the 5.10 bump in our requirements? Is it something we can work around? (I'm in general OK with updating our requirements, but have been dinged on this from users enough times in the last 10 years that I'm more sensitive to it now) 13:04
(wonder if it's an older change that we only just ack'd.) 13:05
unmatched} The commit above just changes the instructions in the INSTALL.txt we were requiring 5.10 for a while
[Coke] ah, it's back to pre christmas. carry on. 13:06
unmatched} It's actually 5.10.1 or something like that. Yesterday, a person in #perl6 was on 5.10.0 and one of the core modules was missing a sub we're using
(or something that we use uses that; I couldn't find the call in rakudo repo)
dogbert17 o/ is lizmat around? 13:10
there is a problem with the latest commit, this is what happens when I type 'rakudobrew build moar' 13:11
lizmat is around again
dogbert17 ... HEAD is now at 02b2e30... Bump NQP to get the latest MoarVM async improvements 13:12
Unrecognized revision specifier 'parrot-22-g377c365'
Failed running /usr/bin/perl Configure.pl --backends=moar --gen-moaryes
lizmat eh>
?
jnthn Hmm
unmatched} "--gen-moaryes" ? Spurious "yes"? 13:13
dogbert17 has worked flawlessly for months until now
jnthn I don't think parrot- is right...it's meant to be against the last NQP release...
dogbert17 the 'yes' is from weechat when it asked if I wanted to paste two lines
lizmat $ git describe 13:14
parrot-22-g377c365
jnthn: that's what nqp gives me
I think that's a result of the tag that moritz++ added for the parrot support removal
jnthn git describe --match 2* 13:15
Yeah
Guess we gotta be carefuller this month
lizmat ok, lemme try that
argh, some wip slipped in... 13:18
jnthn So wip it out again! 13:19
dalek kudo/nom: 61725d7 | lizmat++ | tools/build/NQP_REVISION:
Properly bump NQP, jnthn++

We had a parrot tag in there. But we should really be relative to the release, so "git describe --match e*" is the incantation to get the tag to bump the NQP version dependency with.
13:20
lizmat wipped out :-)
dogbert17: could you check again ?
dogbert17 trying ...
works, lizmat++, jnthn++ 13:21
lizmat dogbert17++ # quick report :-)
DrForr WIP it good. 13:32
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Properly bump NQP, jnthn++ 14:38
travis-ci.org/rakudo/rakudo/builds/148308314 github.com/rakudo/rakudo/compare/0...725d7f7ce8
psch heh, that's moar not generating more output after interp.c 14:41
i'm strongly inclined to blame travis for that kind of failure
i mean, interp.c *definitely* shouldn't take 10 minutes
TimToady well, if it's using clang... 15:18
timotimo it could be fixed by having -j2 be the default 15:19
and maybe we're able to move interp.c to the beginning?
psch i don't think we have to react in any way. it's just travis being unreliable 16:24
just like yesterday the over-ten-minutes stage parse on r-j 16:32
[Coke] if travis is unreliable, how can we rely on it? (we're just going to start ignoring failures, so why use it?) 16:50
timotimo we can manually inspect the failure mode to see if it's sensible 16:51
psch [Coke]: well, "no output for 10 minutes" is definitely a meaningless error, since nothing we have encountered that produced it could sensibly be our fault
mst [Coke]: if you regard travis as a mini-cpantesters, it's still useful. 16:53
it doesn't have to be 100% reliable for the results to still provide utility
unmatched}
.oO( make a bot that would report when the failure is due to the timeout... )
16:54
timotimo that'd be a nice thing to have, tbh
TimToady m: say (1 ... *).grep(*.is-prime).is-lazy; 17:16
camelia rakudo-moar 61725d: OUTPUT«False␤»
TimToady looks like grep needs the .lazy-if($laze) treatment 17:17
timotimo sharks with friggin lazers
unmatched} ( ticket: rt.perl.org/Ticket/Display.html?id=128773 ) 17:22
TimToady thanks 17:24
unmatched} m: say (grep *.is-prime, (1 ... *)).is-lazy; 17:49
camelia rakudo-moar 61725d: OUTPUT«True␤»
unmatched} bisect: m: say (1 ... *).grep(*.is-prime).is-lazy; 17:50
bisectable unmatched}: On both starting points the exit code is 0 and the output is identical as well
unmatched}: Output on both points: False
TimToady unmatched}: that works because the functional form reads: 17:51
multi sub grep(Mu $test, +values, *%a) { my $laze = values.is-lazy; values.grep($test,|%a).lazy-if($laze)
}
dalek kudo/nom: 7ba6dbf | TimToady++ | src/Perl6/Actions.nqp:
propagate outer wanted to logical thunks

Fixes RT #128770
17:52
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128770
travis-ci Rakudo build passed. TimToady 'propagate outer wanted to logical thunks 18:48
travis-ci.org/rakudo/rakudo/builds/148377110 github.com/rakudo/rakudo/compare/6...a6dbfae97f
dalek kudo/nom: fc28b67 | TimToady++ | src/Perl6/Actions.nqp:
[op] onearg should want op and onearg

Fixes RT #128766
18:49
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128766
travis-ci Rakudo build errored. TimToady '[op] onearg should want op and onearg 19:46
travis-ci.org/rakudo/rakudo/builds/148394739 github.com/rakudo/rakudo/compare/7...28b67185d7
tbrowder emacs users: I just added new indices to my fork of perl6-mode. not perfect but it shows var names with sigil, classes, and subs (all types including proto); feature requests accepted (syohex is helping with good criticism); my additions are in my forks's branch "my-branch" 20:00
dalek kudo/nom: 22949d8 | lizmat++ | src/core/Any-iterable-methods.pm:
Fix for RT #128773
21:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128773
Zoffix :o 21:24
That's about 1000% simpler than what I imagined it'd be when I looked at the code this afternoon :)
lizmat don't you love roles ?
Zoffix :D
geekosaur (role with it...) 21:25
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix for RT #128773' 22:09
travis-ci.org/rakudo/rakudo/builds/148430884 github.com/rakudo/rakudo/compare/f...949d8efef1
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128773
lizmat good night, #perl6-dev 22:10
timotimo gnite liz
Zoffix 🎺🎺🎺 New blog post "IRC::Client: Perl 6 Multi-Server IRC (or Awesome Async Interfaces with Perl 6)": perl6.party/post/IRC-Client-Perl-6-...IRC-Module 23:27
timotimo damn, i never tried having a regex match in a signature inside a where clause; it's really nifty you get the $/ in the routine body! 23:38
Zoffix yeah
timotimo i find it a bit surprising that you chose to have NEXT as an attribute 23:39
where most libraries i know that have something like that will pass a next that you have to invoke in the arguments
timotimo continues reading
Zoffix I added it before I realized I could make multi-dispatch using regexes on a Message Object's attribute. I've not needed it for any of the examples so far... ¯\_(ツ)_/¯ 23:40
(well, other than the example that shows a .NEXT :P) 23:41
timotimo mhm 23:43
the thing is, the NEXT that you usually get is to identify multiple simultaneous requests that are in-flight 23:44
when you want to asynchronously handle stuff
Zoffix Not sure how that applies here. In IRC::Client, .NEXT signals that the event should be passed further down the chain, usually as an indicator that the current handler was unable to handle it, or because the current handler is a preprocessor for the event. 23:48
That's why I've not had a chance to use it yet, because my handlers are matched by the signature constraint, so whenever they get entered is because they can definitly handle the output 23:49
timotimo mh, so a plugin is allowed to mutate the content of the event? 23:50
and so, but simply 23:58
^- should probably be "by simply"