| 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" |