[perl #130099] .defined doesn't work with junctions
# New Ticket Created by Lloyd Fournier # Please include the string: [perl #130099] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130099 > < llfourn> m: say defined all(Any,"foo") # Why is this true? Shouldn't it autothread? <+camelia> rakudo-moar 59bb1b: OUTPUT«True» < lizmat> llfourn: that feels like a bug Expected behaviour is that it should autothread and call .defined on the values in the junction. https://irclog.perlgeek.de/perl6/2016-11-14#i_13563873 ^ Lizmat++ tried a quickfix but it didn't work so rakudobugging so it can be addressed later.
[perl #130031] [BUG][BUILD] gmake install step fails under Windows for 2016.10 with the Strawberry Perl buildchain
This has been fixed by https://github.com/MoarVM/MoarVM/commit/404ed261be00e2 I see an already-existing test for mkdir in S32-io/mkdir_rmdir.t, so I think this one just slipped through due to being Windows-specific. On Mon, 07 Nov 2016 05:18:43 -0800, 1parr...@gmail.com wrote: > I've also encountered a problem with "make" blowing up, on a Raspberry > Pi, which I haven't yet investigated in enough detail to report > formally. I first attributed it to some peculiarity of the > environment, but this sounds an awful lot like the same problem. > > On 11/6/16, Steve Mynott wrote: > > # New Ticket Created by Steve Mynott > > # Please include the string: [perl #130031] > > # in the subject line of all future correspondence about this issue. > > # https://rt.perl.org/Ticket/Display.html?id=130031 > > > > > > > Although discovered while trying to create Rakudo Star 2016.10 > > binaries for > > Windows I also see the same error with the plain Rakudo 2016.10 > > release. I > > had no problems doing the same with 2016.07. > > > > Using the gcc and gmake supplied with Strawberry Perl the final > > "gmake > > install" step fails with > > > > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e cp > > perl6.moarvm > > perl6-debug.moarvm C:\rakudo/share/perl6/runtime > > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e mkpath > > C:\rakudo/share/perl6/runtime/dynext > > C:\Strawberry\perl\bin\perl.exe -MExtUtils::Command -e cp > > dynext/perl6_ops_moar.dll C:\rakudo/share/perl6/runtime/dynext > > .\perl6-m.bat tools/build/upgrade-repository.pl C:\rakudo/share/perl6 > > Failed to create directory 'C:\rakudo\share\perl6\resources' with > > mode > > '0o777': Failed to mkdir: 2 > > in any at ././CORE.setting.moarvm line 1 > > in block at tools/build/upgrade-repository.pl line 1 > > > > Actually thrown at: > > in block at tools/build/upgrade-repository.pl line 1 > > > > makefile:553: recipe for target 'm-install' failed > > gmake[1]: *** [m-install] Error 1 > > gmake[1]: Leaving directory > > 'C:/Users/steve/Downloads/rakudo-star-2016.10/rakudo' > > makefile:53: recipe for target 'rakudo-install' failed > > gmake: *** [rakudo-install] Error 2 > > > > -- > > 4096R/EA75174B Steve Mynott > >
[perl #130095] MAST::Frame error encountered.
# New Ticket Created by Clifton Wood # Please include the string: [perl #130095] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130095 > While working on a Perl project, I ran into an odd error trying to create a test script. You can find the entire project, here: https://github.com/Xliff/p6-xslt I have attached the relevant scripts to this message. The error message follows: cbwood@infinity:~/projects/p6-xml-xslt$ perl6 --ll-exception -I ../p6-XML-LibXML-work/lib -I lib t/01-basic.t Expected MAST::Frame, but didn't get one at gen/moar/stage2/QAST.nqp:6644 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/QAST.moarvm:assemble_to_file) from gen/moar/stage2/NQPHLL.nqp:407 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:mbc) from gen/moar/stage2/NQPHLL.nqp:1677 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:compile) from gen/moar/stage2/NQPHLL.nqp:1410 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval) from gen/moar/stage2/NQPHLL.nqp:1631 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:evalfiles) from gen/moar/stage2/NQPHLL.nqp:1525 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval) from src/Perl6/Compiler.nqp:27 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval) from gen/moar/stage2/NQPHLL.nqp:1499 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_line) from gen/moar/m-main.nqp:47 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:MAIN) from gen/moar/m-main.nqp:38 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:) from :1 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:) from :1 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:) at gen/moar/m-CORE.setting:26689 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:throw) from gen/moar/m-CORE.setting:800 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:die) from gen/moar/m-CORE.setting:788 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:die) from gen/moar/m-CORE.setting:42965 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile) from gen/moar/m-CORE.setting:42887 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile) from gen/moar/m-CORE.setting:42727 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:try-load) from gen/moar/m-CORE.setting:43668 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:) from gen/moar/m-CORE.setting:43661 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:need) from gen/moar/m-CORE.setting:43688 (/home/cbwood/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:need) from src/Perl6/World.nqp:1199 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:load_module) from src/Perl6/World.nqp:1129 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:do_pragma_or_load_module) from src/Perl6/Grammar.nqp:1565 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control:sym) from gen/moar/stage2/QRegex.nqp:1371 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex) from :1 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control) from src/Perl6/Grammar.nqp:1251 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement) from src/Perl6/Grammar.nqp:1180 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist) from gen/moar/stage2/NQPHLL.nqp:1011 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:LANG) from src/Perl6/Grammar.nqp:1579 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG) from src/Perl6/Grammar.nqp:1164 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit) from src/Perl6/Grammar.nqp:467 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP) from gen/moar/stage2/QRegex.nqp:2093 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1718 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1674 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:compile) from gen/moar/stage2/NQPHLL.nqp:1410 (/home/cbwood/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval) from gen/moar/stage2/NQPHLL.nqp:1631
[perl #130099] .defined doesn't work with junctions
Thanks for the report. Fixed in https://github.com/rakudo/rakudo/commit/189cb23e84 Tests added in https://github.com/perl6/roast/commit/6b84580ecc On Mon, 14 Nov 2016 04:37:49 -0800, lloyd.fo...@gmail.com wrote: > < llfourn> m: say defined all(Any,"foo") # Why is this true? Shouldn't it > autothread? > <+camelia> rakudo-moar 59bb1b: OUTPUT«True» > < lizmat> llfourn: that feels like a bug > > Expected behaviour is that it should autothread and call .defined on the > values in the junction. > > https://irclog.perlgeek.de/perl6/2016-11-14#i_13563873 > ^ Lizmat++ tried a quickfix but it didn't work so rakudobugging so it can > be addressed later.
[perl #130095] MAST::Frame error encountered.
Thanks for the report. Would you provide a working example we can reproduce with? For example, with the repo you linked, I'm getting "Could not find XML::LibXML::CStructs at line 5 in:" and no such module in the ecosystem. Also, what Perl 6 version are you using? (perl6 -v) On Sun, 13 Nov 2016 23:16:43 -0800, clifton.w...@gmail.com wrote: > While working on a Perl project, I ran into an odd error trying to > create a > test script. > > You can find the entire project, here: https://github.com/Xliff/p6- > xslt > > I have attached the relevant scripts to this message. > > The error message follows: > > cbwood@infinity:~/projects/p6-xml-xslt$ perl6 --ll-exception -I > ../p6-XML-LibXML-work/lib -I lib t/01-basic.t > Expected MAST::Frame, but didn't get one >at gen/moar/stage2/QAST.nqp:6644 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/QAST.moarvm:assemble_to_file) > from gen/moar/stage2/NQPHLL.nqp:407 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:mbc) > from gen/moar/stage2/NQPHLL.nqp:1677 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:compile) > from gen/moar/stage2/NQPHLL.nqp:1410 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:eval) > from gen/moar/stage2/NQPHLL.nqp:1631 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:evalfiles) > from gen/moar/stage2/NQPHLL.nqp:1525 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval) > from src/Perl6/Compiler.nqp:27 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval) > from gen/moar/stage2/NQPHLL.nqp:1499 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:command_line) > from gen/moar/m-main.nqp:47 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/perl6.moarvm:MAIN) > from gen/moar/m-main.nqp:38 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/perl6.moarvm:) > from :1 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/perl6.moarvm:) > from :1 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/perl6.moarvm:) > > at gen/moar/m-CORE.setting:26689 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:throw) > from gen/moar/m-CORE.setting:800 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:die) > from gen/moar/m-CORE.setting:788 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:die) > from gen/moar/m-CORE.setting:42965 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile) > from gen/moar/m-CORE.setting:42887 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:precompile) > from gen/moar/m-CORE.setting:42727 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:try-load) > from gen/moar/m-CORE.setting:43668 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:) > from gen/moar/m-CORE.setting:43661 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:need) > from gen/moar/m-CORE.setting:43688 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/perl6/runtime/CORE.setting.moarvm:need) > from src/Perl6/World.nqp:1199 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/World.moarvm:load_module) > from src/Perl6/World.nqp:1129 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/World.moarvm:do_pragma_or_load_module) > from src/Perl6/Grammar.nqp:1565 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control:sym) > from gen/moar/stage2/QRegex.nqp:1371 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/QRegex.moarvm:!protoregex) > from :1 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement_control) > from src/Perl6/Grammar.nqp:1251 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement) > from src/Perl6/Grammar.nqp:1180 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist) > from gen/moar/stage2/NQPHLL.nqp:1011 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:LANG) > from src/Perl6/Grammar.nqp:1579 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG) > from src/Perl6/Grammar.nqp:1164 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit) > from src/Perl6/Grammar.nqp:467 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP) > from gen/moar/stage2/QRegex.nqp:2093 > (/home/cbwood/.rakudobrew/moar- > nom/install/share/nqp/lib/QRegex.moarvm:parse) > from gen/moar/stage2/NQPHLL.nqp:1718 > (/home/cbwood/.rakud
[perl #130081] [@LARRY] Grammar.parse DWIMs only if your TOP rule has $ on the end
My personal two cents from someone who knows very little about the workings of
grammars and regexes is this is quite a bit of a WAT. `regex` is meant to
backtrack and it does, for example here:
m: say grammar { regex TOP { 'foo' }; regex foo { [ ‘a’ ||
‘abc’ ] } }.parse: 'abcfoo'
rakudo-moar dfb58d: OUTPUT«｢abcfoo｣ foo => ｢abc｣»
m: say grammar { regex TOP { 'foo' }; token foo { [ ‘a’ ||
‘abc’ ] } }.parse: 'abcfoo'
rakudo-moar dfb58d: OUTPUT«Nil»
However, if the `regex` is a top-level rule, then we add an extra requirement
that to enable backtracking the user also needs an anchor to the end of string.
It's a special exception to the rule and would need to be documented in Traps,
but why do we have it?
On Sat, 12 Nov 2016 18:36:15 -0800, alex.jakime...@gmail.com wrote:
> To demonstrate how it works, let's say we have this grammar:
>
> grammar G { regex TOP { ‘a’ || ‘abc’ } };
>
> So you might think that it will match either “a” or “abc”, but no,
> “abc”
> will never work.
>
> *Code:*
> grammar G { regex TOP { ‘a’ || ‘abc’ } };
> say G.parse(‘abc’)
>
> *Result:*
> Nil
>
> Why? Well, see this:
> https://github.com/rakudo/rakudo/blob/cb8f783eeb8ab25a5090fdc4e5cc318c36ee1afa/src/core/Grammar.pm#L23
>
> Basically, TOP will first match ‘a’, and given that it is a good
> enough
> result it will bail out without trying anything else. Then, .parse
> method
> will see that it did not parse the whole string, so it fails.
>
> I am not sure how this behavior could be useful or even how could
> anyone
> expect this, to me it feels like the top rule should always have an
> implicit $ on the end so that it knows that it should keep trying to
> find a
> better solution.
>
> But yes, we can close our eyes on this issue and add yet another trap
> to
> the documentation.
>
> Another closely related issue is method .subparse. As it seems,
> subparse is
> supposed to return partial results (.partial-parse ?), but for some
> reason
> instead of returning Nil it returns a failed Match, unlike .parse.
CALL-ME vs. Callable
This started out some weeks ago as a user in #perl6 confused by an error
that gofled down to:
[28 19:01:37] m: my Bool $x = False; $x()
[28 19:01:38] rakudo-moar 0dc6f7: OUTPUT«No such method 'CALL-ME'
for invocant of type 'Bool'
This is, at the very least, LTA. But it also got me thinking about the spec.
The obvious way to clean up the above, and some more complicated things of
the same sort, is to hide the obviously-internal CALL-ME behind a role,
which arguably should be part of the spec as well to let implementations
provide a stable interface while doing whatever is necessary for the
backend in its implementation. The obvious name for this role is Callable.
But, we already have a role Callable which is a mixin that adds
functionality to things that are callable, and is part of 6.c's spec. This
seems like a design flaw, and looks like it's going to be hard to fix, or
at least to make rational when other roles describe things that *are*
something instead of describing what they *modify*.
Is there a way forward on this that makes any sense?
(for the record, the proposed wrapper role looks something like
role OughtToBeCallable { # bikeshed pending paint job...
method CALL(|c) {...}; # CALL-ME happens here
}
and the 4 places that currently build a CALL-ME in nqp would have a type
OughtToBeCallable added so that the runtime CALL-ME error becomes a
compile-time failed OughtToBeCallable constraint with a user-comprehensible
error.)
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
Role-based testing seems very perl6ish. I'd suggest the role name be
"Invocable" with much the sort of signature as you've described.
That being said, I don't think that the current error is terrible. It
clearly shows that the issue is with the attempt to invoke a Bool.
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.
On Mon, Nov 14, 2016 at 2:32 PM, Brandon Allbery
wrote:
> This started out some weeks ago as a user in #perl6 confused by an error
> that gofled down to:
>
> [28 19:01:37] m: my Bool $x = False; $x()
> [28 19:01:38] rakudo-moar 0dc6f7: OUTPUT«No such method
> 'CALL-ME' for invocant of type 'Bool'
>
> This is, at the very least, LTA. But it also got me thinking about the
> spec.
>
> The obvious way to clean up the above, and some more complicated things of
> the same sort, is to hide the obviously-internal CALL-ME behind a role,
> which arguably should be part of the spec as well to let implementations
> provide a stable interface while doing whatever is necessary for the
> backend in its implementation. The obvious name for this role is Callable.
> But, we already have a role Callable which is a mixin that adds
> functionality to things that are callable, and is part of 6.c's spec. This
> seems like a design flaw, and looks like it's going to be hard to fix, or
> at least to make rational when other roles describe things that *are*
> something instead of describing what they *modify*.
>
> Is there a way forward on this that makes any sense?
>
> (for the record, the proposed wrapper role looks something like
>
> role OughtToBeCallable { # bikeshed pending paint job...
> method CALL(|c) {...}; # CALL-ME happens here
> }
>
> and the 4 places that currently build a CALL-ME in nqp would have a type
> OughtToBeCallable added so that the runtime CALL-ME error becomes a
> compile-time failed OughtToBeCallable constraint with a
> user-comprehensible error.)
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
Re: CALL-ME vs. Callable
On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman wrote: > That being said, I don't think that the current error is terrible. It > clearly shows that the issue is with the attempt to invoke a Bool. In that situation it is obvious, because I took the simplest of the 4 cases when nqp hauls a CALL-ME out of its bowels. In the original it was less so; some of the cases are obscure at best. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
Also... On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman wrote: > Role-based testing seems very perl6ish. I'd suggest the role name be > "Invocable" with much the sort of signature as you've described. If it's Invokable then the method should probably be INVOKE. It still leaves the question of why Callable appears to be the only role named after what it applies to instead of what it provides. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
Fair points, all. I do think, though that if the concern is really with "the 4 cases when nqp hauls a CALL-ME out of its bowels" then that's what should be addressed... Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long student. On Mon, Nov 14, 2016 at 3:22 PM, Brandon Allbery wrote: > Also... > > On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman wrote: > >> Role-based testing seems very perl6ish. I'd suggest the role name be >> "Invocable" with much the sort of signature as you've described. > > > If it's Invokable then the method should probably be INVOKE. It still > leaves the question of why Callable appears to be the only role named > after what it applies to instead of what it provides. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
Re: CALL-ME vs. Callable
On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman wrote:
> I do think, though that if the concern is really with "the 4 cases when
> nqp hauls a CALL-ME out of its bowels" then that's what should be
> addressed...
>
The main addressing of that is some kind of role to abstract it properly. I
just think the current situation is bad and even if we come up with a name
for the new role, it's still going to be confusing ("ok, why do we have
both Callable and Invokable? ...uh wait, Callable means *what* exactly?").
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
So, you said that the problem arises because NQP does something non-obvious
that results in this error. Can you be clear on what that non-obvious
behavior is? It sounds to me like you're addressing a symptom of a systemic
issue.
Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.
On Mon, Nov 14, 2016 at 4:08 PM, Brandon Allbery
wrote:
>
> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman wrote:
>
>> I do think, though that if the concern is really with "the 4 cases when
>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>> addressed...
>>
>
> The main addressing of that is some kind of role to abstract it properly.
> I just think the current situation is bad and even if we come up with a
> name for the new role, it's still going to be confusing ("ok, why do we
> have both Callable and Invokable? ...uh wait, Callable means *what*
> exactly?").
>
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
Re: CALL-ME vs. Callable
On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman wrote: > So, you said that the problem arises because NQP does something > non-obvious that results in this error. Can you be clear on what that > non-obvious behavior is? It sounds to me like you're addressing a symptom > of a systemic issue. That's pretty much the definition of LTA. The programmer did something that on some level involves a call (in the simple example it was explicit, but there are some implicit ones in the language), and got a runtime error referencing an internal name instead of something preferably compile time related to what they wrote. The fix for this is to abstract it into a role that describes "calling"/"invoking" instead of having a CALL-ME that the user didn't (and probably shouldn't) define suddenly pop up out of nowhere. That isn't the part that's difficult, aside from "so why wasn't it done that way to begin with?". -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
This should probably have been cc-d to the list.
Callable claims to be the thing we want. What it actually is, is a mix-in
that adds the assuming method. I am not sure these can be conflated.
Note that the current docs actually do claim it is what I want. This is
because I first brought this up in IRC while the documentation for Callable
was being written, and it got modified to match my then current musings
because nobody who actually works on the spec was around. I had in fact
specified that this was a "would be nice" but that I wasn't sure if it
would actually work; I have since concluded that it likely won't, and needs
to be a distinct role. Which is part of why I brought this up: the current
doc does not match what currently happens, and may not actually be
implementable without breaking the spec (that is, 6.d would have a
fundamental conflict with 6.c over the meaning of Callable).
On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang wrote:
> Okay, let's go with that. What does Callable do, and why is it called that?
>
> On Nov 14, 2016 1:09 PM, "Brandon Allbery" wrote:
>
>>
>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman wrote:
>>
>>> I do think, though that if the concern is really with "the 4 cases when
>>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>>> addressed...
>>>
>>
>> The main addressing of that is some kind of role to abstract it properly.
>> I just think the current situation is bad and even if we come up with a
>> name for the new role, it's still going to be confusing ("ok, why do we
>> have both Callable and Invokable? ...uh wait, Callable means *what*
>> exactly?").
>>
>>
>> --
>> brandon s allbery kf8nh sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
So what is the assuming method, and why is it in a callable role? What was
the logic behind that decision?
On Nov 14, 2016 1:38 PM, "Brandon Allbery" wrote:
> This should probably have been cc-d to the list.
>
> Callable claims to be the thing we want. What it actually is, is a mix-in
> that adds the assuming method. I am not sure these can be conflated.
>
> Note that the current docs actually do claim it is what I want. This is
> because I first brought this up in IRC while the documentation for
> Callable was being written, and it got modified to match my then current
> musings because nobody who actually works on the spec was around. I had in
> fact specified that this was a "would be nice" but that I wasn't sure if it
> would actually work; I have since concluded that it likely won't, and needs
> to be a distinct role. Which is part of why I brought this up: the current
> doc does not match what currently happens, and may not actually be
> implementable without breaking the spec (that is, 6.d would have a
> fundamental conflict with 6.c over the meaning of Callable).
>
> On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang wrote:
>
>> Okay, let's go with that. What does Callable do, and why is it called
>> that?
>>
>> On Nov 14, 2016 1:09 PM, "Brandon Allbery" wrote:
>>
>>>
>>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman wrote:
>>>
I do think, though that if the concern is really with "the 4 cases
when nqp hauls a CALL-ME out of its bowels" then that's what should be
addressed...
>>>
>>> The main addressing of that is some kind of role to abstract it
>>> properly. I just think the current situation is bad and even if we come up
>>> with a name for the new role, it's still going to be confusing ("ok, why do
>>> we have both Callable and Invokable? ...uh wait, Callable means *what*
>>> exactly?").
>>>
>>>
>>> --
>>> brandon s allbery kf8nh sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>
>
> --
> brandon s allbery kf8nh sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
Re: CALL-ME vs. Callable
On Mon, Nov 14, 2016 at 5:00 PM, Jon Lang wrote: > So what is the assuming method, and why is it in a callable role? What was > the logic behind that decision? It's perfectly sensible: it's how you implement partial application (which as sadly usual is mis-called "currying"). &some-callable.assuming(foo) is a callable (and a Callable; note however that some-callable is not necessarily a Callable!) which, when invoked, invokes some-callable(foo, <*parameters to invocation here*>). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: CALL-ME vs. Callable
I guess I wasn't clear in what I was asking: What, exactly, was it that NQP was doing? What were the inputs and what was the behavior that you observed? So far, all I have to go on is one example that you feel is not illustrating the broken behavior of NQP that you want to work around with a change to the way Callable and calling work. I'm not suggesting that the latter is bad, but it seems to be a patch around a problem in the former... Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long student. On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery wrote: > > On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman wrote: > >> So, you said that the problem arises because NQP does something >> non-obvious that results in this error. Can you be clear on what that >> non-obvious behavior is? It sounds to me like you're addressing a symptom >> of a systemic issue. > > > That's pretty much the definition of LTA. The programmer did something > that on some level involves a call (in the simple example it was explicit, > but there are some implicit ones in the language), and got a runtime error > referencing an internal name instead of something preferably compile time > related to what they wrote. The fix for this is to abstract it into a role > that describes "calling"/"invoking" instead of having a CALL-ME that the > user didn't (and probably shouldn't) define suddenly pop up out of nowhere. > That isn't the part that's difficult, aside from "so why wasn't it done > that way to begin with?". > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
Re: CALL-ME vs. Callable
I feel like you're focusing on the wrong thing somehow. The issue is not that what nqp is doing is somehow wrong. The issue is that the thing it is doing is necessarily an implementation detail, and as such should be isolated from the language level and any failures/errors exposed as language level instead of leaking implementation details the programmer should not have to care about. The Perl 6 way to do this is to wrap it in a role that is documented at language level; in this case, I don't think it is necessary for that role to translate errors between levels (this often is needed in other such isolation-layer roles), since most (possibly all) of the errors become language level compile time errors. On Mon, Nov 14, 2016 at 5:08 PM, Aaron Sherman wrote: > I guess I wasn't clear in what I was asking: > > What, exactly, was it that NQP was doing? What were the inputs and what > was the behavior that you observed? So far, all I have to go on is one > example that you feel is not illustrating the broken behavior of NQP that > you want to work around with a change to the way Callable and calling work. > I'm not suggesting that the latter is bad, but it seems to be a patch > around a problem in the former... > > > > > Aaron Sherman, M.: > P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com > Toolsmith, developer, gamer and life-long student. > > > On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery > wrote: > >> >> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman wrote: >> >>> So, you said that the problem arises because NQP does something >>> non-obvious that results in this error. Can you be clear on what that >>> non-obvious behavior is? It sounds to me like you're addressing a symptom >>> of a systemic issue. >> >> >> That's pretty much the definition of LTA. The programmer did something >> that on some level involves a call (in the simple example it was explicit, >> but there are some implicit ones in the language), and got a runtime error >> referencing an internal name instead of something preferably compile time >> related to what they wrote. The fix for this is to abstract it into a role >> that describes "calling"/"invoking" instead of having a CALL-ME that the >> user didn't (and probably shouldn't) define suddenly pop up out of nowhere. >> That isn't the part that's difficult, aside from "so why wasn't it done >> that way to begin with?". >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
rakudo bug 128427 perl 5 does not build on Darwin platforms with clock_gettime
Hi, Turns out this bug was filed for p5 (I thought I was looking at the p6 bug list) but I saw this exactly today, trying to build, via rakudobrew, on my mac book. Just checking if this is a known thing or not. -- a Andy Bach, afb...@gmail.com 608 658-1890 cell 608 261-5738 wk
Re: [perl #130099] .defined doesn't work with junctions
Thanks! On Tue, Nov 15, 2016 at 1:28 AM Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > Thanks for the report. > > Fixed in https://github.com/rakudo/rakudo/commit/189cb23e84 > Tests added in https://github.com/perl6/roast/commit/6b84580ecc > > > On Mon, 14 Nov 2016 04:37:49 -0800, lloyd.fo...@gmail.com wrote: > > < llfourn> m: say defined all(Any,"foo") # Why is this true? Shouldn't it > > autothread? > > <+camelia> rakudo-moar 59bb1b: OUTPUT«True» > > < lizmat> llfourn: that feels like a bug > > > > Expected behaviour is that it should autothread and call .defined on the > > values in the junction. > > > > https://irclog.perlgeek.de/perl6/2016-11-14#i_13563873 > > ^ Lizmat++ tried a quickfix but it didn't work so rakudobugging so it can > > be addressed later. > > > >
