[perl #127864] Strange MAIN positional string interpolations
>S19 specifies s/specifies/speculated/ ... :)
[perl #127864] Strange MAIN positional string interpolations
On Fri Apr 08 19:39:49 2016, madcap.russo...@gmail.com wrote:
> From IRC:
> 9:22 PM if I pass a : at the beginning of a string
> argument to MAIN, it fails to match any signatures and triggers the
> Usage message
> 9:25 PM MadcapJake, can't reproduce. What's the sig for
> MAIN you're using and what's the way you're calling the script with?
> 9:25 PM ./bin/rabble -e -d ": addone 1 + ; 1 addone ."
> 9:26 PM MadcapJake, but the usage message tells you to use
> -d="..." doesn't it? You're missing the equals sign
> 9:26 PM no, those are Bools
> 9:27 PM ~/github/rabble/bin/rabble --expression|-e [--
> debug|-d]
> 9:27 PM ~/github/rabble/bin/rabble [--debug|-d]
> 9:28 PM MadcapJake, confirmed on my box. You should
> rakudobug this: perl6 -e 'sub MAIN ($x) {}' ": 42" <-- triggers
> usage... perl6 -e 'sub MAIN ($x) {}' "42" <-- no usage
> 9:28 PM :(Str $expr, Bool :expression(:$e)!, Bool
> :debug(:$d)) is the signature I'm trying to match
> 9:29 PM The bug seems to exist with a single positional as
> well. A ":" as the first char in the positional breaks something
> 9:33 PM MadcapJake, are you rakudobugging it? I found this
> works: to set $y to 45: perl6 -e 'sub MAIN ($x, :$y) { say $y }'
> ":y=45" 42
> 9:34 PM In addition it's also impossible to pass "-y=45"
> to a positional argument, because it gets interpreted as a named arg,
> it seems
> 9:35 PM ZoffixWin: even if you do -- first ?
> 9:35 PM teatime, was about to say the -- is the way.
> 9:35 PM This is more about the shell than Perl 6, but :y
> should still be parsed as normal string and not a named arg IMO
> 9:36 PM perl6 -e 'sub MAIN ($x) { say $x }' -- ":y=45"
> works fine
> 9:36 PM Unless there are some shells where : instead of -
> on args is used that I'm unaware of.
S19 specifies
Options must begin with one of the following symbols: --, -, or :.
So this is not up to the shell, but the interpreter.
Of course, that doesn't change that there's something weird. Consider the
following examples:
$ ./perl6-m --version
This is Rakudo version 2016.03-106-gd847011 built on MoarVM version
2016.03-104-g10d3971
implementing Perl 6.c.
$ ./perl6-m "--version"
This is Rakudo version 2016.03-106-gd847011 built on MoarVM version
2016.03-104-g10d3971
implementing Perl 6.c.
$ ./perl6-m -e'multi MAIN($a) { say "pos" }; multi MAIN(:$a) { say "named" }'
":a"
named
$ ./perl6-m -e'multi MAIN($a) { say "pos" }; multi MAIN(:$a) { say "named" }'
-- ":a"
named
$ ./perl6-m -e'multi MAIN($a) { say "pos" }; multi MAIN(:$a) { say "named" }'
-- "--a"
named
$ ./perl6-m -e'multi MAIN($a) { say "pos" }; multi MAIN(:$a) { say "named" }'
"--a"
Illegal option --a
[rest of < perl6 --help > here]
The last case is probably the most interesting one... :)
In any case, what actually seems to be wrong is that the interpreter can't
distinguish between quoted arguments that look like switches and non-quoted
switches, and -- as "only arguments from here on" doesn't seem to work
completely reliably either.
[perl #127916] [BUG] Inaccurate assignment to $!shortname in cases where a mixin happens during BUILD time.
On Wed Apr 20 02:54:29 2016, jn...@jnthn.net wrote:
> On Sun Apr 17 16:34:02 2016, pesc...@gmail.com wrote:
> > Consider the following snippet:
> >
> > 23:28 < psch> m: role Bar::Foo { }; class A { submethod BUILD { self
> > does Bar::Foo } }; A.new.WHAT.say
> > 23:28 <+camelia> rakudo-moar 617bb4: OUTPUT«(Foo})»
> >
> > Clearly, A is not of type 'Foo}'. As far as I can tell
> > Perl6::Metamodel::Naming is involved, although I'm not sure why this
> > only happens with mixins during BUILD. I'd expect .WHAT to report
> > 'A+{Bar::Foo}' instead.
>
> Nothing to do build BUILD. It golfs to:
>
> role Foo::Bar { }; say (42 but Foo::Bar).^shortname
>
> And it'll be because of this overly-naive code:
>
> https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Metamodel/Naming.nqp#L6
>
> Maybe set_name should take an optional second parameter for the short
> name, and the mixin code can set it explicitly.
>
> /jnthn
Fixed in Rakudo commit 60550d15, test added in roast commit 95a5c18.
[perl #127988] [BUG] Lack of space after != operator changes behaviour
On Mon Apr 25 09:20:43 2016, c...@zoffix.com wrote: > > If the programmer omits the space after the != (not equal, numeral) > operator, the behavior of the operator changes to: [assign RHS to LHS, > return !RHS], as can be seen from these examples: > > m: say 0 != 0 > rakudo-moar f05c77: OUTPUT«False» > m: say 0 !=0 > rakudo-moar f05c77: OUTPUT«Cannot modify an immutable Int > in block at /tmp/7Z5OWfl3Go line 1» > m: my $x = 42; say $x !=0; say $x > rakudo-moar f05c77: OUTPUT«True0» > m: my $x = 0; say $x !=42; say $x > rakudo-moar f05c77: OUTPUT«False42» > > This behaviour is confusing and probably not wanted by most > programmers. This is a dupe of https://rt.perl.org/Ticket/Display.html?id=121108, which is wrongly titled at the moment.
[perl #124628] [JVM] doesn't know about signals
NQP commit d54d719311 and Rakudo commit 1acf805b6 add a workaround for the lack of actual signal handling on the JVM. Note this is for now limited to SIGINT and SIGKILL, and cannot work for any signal that doesn't want the receiving process to exit.
[perl #127949] [JVM] Dying test in S02-literals/allomorphic.t when comparing ComplexStr with infix:
On Sun May 01 08:04:06 2016, pesc...@gmail.com wrote:
> On Thu Apr 21 12:34:10 2016, barto...@gmx.de wrote:
> > On Thu Apr 21 11:53:14 2016, barto...@gmx.de wrote:
> > >
> > > $ perl6-j -e 'say < 8+9i >.re'
> > > Attribute '$!re' is not a native num
> > > in block at -e line 1
> >
> > Oh, looks like rakudo-j has other problems with the attributes of
> > ComplexStr:
> >
> > $ perl6-j 'say < 8+9i >.im'
> > 8
>
> The problem here lies somewhere in the generation of the accessors for
> Complex. We apparently cache the getattr hint for the Attributes in
> Complex and reuse them whenever we call the generated accessor, which
> results in an off-by-one error when we call the same generated
> accessors on a ComplexStr. Perl 6-level workaround would be to turn
> $.re and $.im in Complex into $!re and $!im and supplying an explicit
> accessor. Fixing this inside nqp-j probably involves a lot of
> figuring out where and how attribute hints are cached.
>
> Note that the same problem doesn't occur with IntStr or NumStr because
> they don't have auto-generated accessors, and RatStr gets its
> accessors from the role Rational, which probably gets composed
> differently and thus avoids the issue. I'm not sure about the details
> there, to be honest.
Here's a golf of the underlying problem:
$ ./perl6-j foo.pl6
Attribute '$!foo' is not a native num
in block at foo.pl6 line 13
$ cat foo.pl6
use nqp;
class A { has num $.foo; has num $.baz };
class B { has str $!bar };
class C is A is B {
method new(Num $a, Str $b) {
my \SELF = nqp::create(self);
nqp::bindattr_n(SELF, A, '$!foo', nqp::unbox_n($a));
nqp::bindattr_n(SELF, A, '$!baz', nqp::unbox_n($a));
nqp::bindattr_s(SELF, B, '$!bar', nqp::unbox_s($b));
SELF
}
};
C.new(5e0, "5").foo.WHAT.say
[perl #127949] [JVM] Dying test in S02-literals/allomorphic.t when comparing ComplexStr with infix:
On Thu Apr 21 12:34:10 2016, barto...@gmx.de wrote: > On Thu Apr 21 11:53:14 2016, barto...@gmx.de wrote: > > > > $ perl6-j -e 'say < 8+9i >.re' > > Attribute '$!re' is not a native num > > in block at -e line 1 > > Oh, looks like rakudo-j has other problems with the attributes of > ComplexStr: > > $ perl6-j 'say < 8+9i >.im' > 8 The problem here lies somewhere in the generation of the accessors for Complex. We apparently cache the getattr hint for the Attributes in Complex and reuse them whenever we call the generated accessor, which results in an off-by-one error when we call the same generated accessors on a ComplexStr. Perl 6-level workaround would be to turn $.re and $.im in Complex into $!re and $!im and supplying an explicit accessor. Fixing this inside nqp-j probably involves a lot of figuring out where and how attribute hints are cached. Note that the same problem doesn't occur with IntStr or NumStr because they don't have auto-generated accessors, and RatStr gets its accessors from the role Rational, which probably gets composed differently and thus avoids the issue. I'm not sure about the details there, to be honest.
[perl #126713] [BUG] Literal array interpolation in regex doesn't match as expected.
On Sat Dec 19 19:44:53 2015, pesc...@gmail.com wrote: > On Mon Nov 23 03:52:55 2015, pesc...@gmail.com wrote: > > Consider the following two regexen and their matching output, or lack > > thereof: > > > > 11:39 < psch> m: say "abcd" ~~ /^(a | b | bc | cd)*?$/; my @a = < a b > > bc cd >; say "abcd" ~~ /^(@a)*?$/ > > 11:39 <+camelia> rakudo-moar : OUTPUT«｢abcd｣ 0 => ｢a｣ 0 => ｢b｣ 0 > > => > > ｢cd｣Nil» > > > > S05 says: > > > > An interpolated array: > > > > / @cmds / > > > > is matched as if it were an alternation of its literal elements. > > Ordinarily it matches using junctive semantics: > > > > / [ $(@cmds[0]) | $(@cmds[1]) | $(@cmds[2]) | ... ] / > > > > Taking this literal still matches when written as the long form: > > > > 11:51 m: my @a = < a b bc cd >; say "abcd" ~~ /^( $(@a[0]) | > > $(@a[1]) | $(@a[2]) | $(@a[3]) )*?$/ > > 11:51 rakudo-moar : OUTPUT«｢abcd｣ 0 => ｢a｣ 0 => ｢b｣ 0 => > > ｢cd｣» > > > > With the S05 quote I'd expect the array to interpolate into any of > > the > > two other regexen and produce the same match. > > 03:39 < Juerd> psch: In bug reports I try to read significance in > every character. So given ^(@a)*?$ I wonder why it's anchored, and > why there's a ? after the * > 03:39 < psch> the ? after * allows backtracking > 03:39 < Juerd> Yes, but I'm trying to figure out why that was needed > for the bug to trigger > 03:40 < Juerd> And if it wasn't, then it's not golfed enough yet :) > 03:40 < psch> m: my @a = < a b bc cd >; say "abcd" ~~ /(@a)*/ > 03:40 <+camelia> rakudo-moar 091ee7: OUTPUT«｢abc｣ 0 => ｢a｣ 0 => > ｢bc｣» > 03:40 < psch> right, the report could've been more golfed i guess > 03:41 < Juerd> And it might have been clearer if the two attempts were > not in a single m: > 03:41 < psch> i'm not confident enough to predict the right behavior > i'd say. quoting the synopsis alludes to that > 03:41 < psch> yes, that's definitely true > 03:41 < Juerd> 'cause it took me, well, a few minutes, to realise that > I should have been looking at that Nil in the output, not the rest. 19:24 < psch> m: my @a = < a b bc cd >; say "abcd" ~~ /^([||@a])*?$/ 19:24 <+camelia> rakudo-moar d075c8: OUTPUT«｢abcd｣ 0 => ｢a｣ 0 => ｢b｣ 0 => ｢cd｣» 19:25 < psch> m: my @a = < a b bc cd >; say "abcd" ~~ /^([|@a])*?$/ 19:25 <+camelia> rakudo-moar d075c8: OUTPUT«Nil» 19:25 < psch> so, yeah, i suppose it's "explicit or implicit LTM alternating interpolation of arrays matches differently than bareword LTM alternations" 19:26 < psch> but well, it's still about what S05 actually means, in a way
[perl #129909] [BUG] cannot compile to jar files for client use using --target=jvm
On Tue Oct 18 18:07:05 2016, data...@gmail.com wrote:
> perl6 --target=jvm --ll-exception --output=guess.jar guess.p6
>
>
> java.lang.NullPointerException
>
> in command_eval (gen/jvm/stage2/NQPHLL.nqp:1217)
>
> in command_eval (src/Perl6/Compiler.nqp:27)
>
> in command_line (gen/jvm/stage2/NQPHLL.nqp:1181)
>
> in MAIN (gen/jvm/main.nqp:47)
>
> in (gen/jvm/main.nqp:38)
>
> in (gen/jvm/main.nqp)
>
>
>
> On Tue, Oct 18, 2016 at 4:43 PM, Elizabeth Mattijsen via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> > What happens if you add --ll-exception to the command line?
> >
> > > On 18 Oct 2016, at 05:42, Felipe Valdes (via RT) <
> > perl6-bugs-follo...@perl.org> wrote:
> > >
> > > # New Ticket Created by Felipe Valdes
> > > # Please include the string: [perl #129909]
> > > # in the subject line of all future correspondence about this issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=129909 >
> > >
> > >
> > > I want my clients to be able to run jar files
> > > generated by the perl6 command:
> > >
> > > The program:
> > >
> > > my $num = (1..100).pick;
> > >
> > > my $guess_count = 0;
> > >
> > >
> > > loop {
> > >
> > > my $guess = prompt("guess");
> > >
> > > if $guess == $num {
> > >
> > > say "Well done";
> > >
> > > last;
> > >
> > > }
> > >
> > > if $guess > $num {
> > >
> > > say "Lower";
> > >
> > > }
> > >
> > > if $guess < $num {
> > >
> > > say "Higher";
> > >
> > > }
> > >
> > > if $guess_count == 7 {
> > >
> > > say "you suck!";
> > >
> > > last;
> > >
> > > }
> > >
> > > $guess_count++;
> > >
> > > }
> > >
> > >
> > > the compilation command:
> > >
> > > perl6 --target=jvm --output=guess.jar guess.p6
> > >
> > >
> > > the result:
> > >
> > > ===SORRY!===
> > >
> > > java.lang.NullPointerException
> > >
> > >
> > > The version:
> > >
> > > This is Rakudo version 2016.10-9-g906719c built on JVM
> > >
> > > implementing Perl 6.c.
> > >
> > >
> > > I think the error message is less than awesome.
> > >
> > >
> > > Felipes-MacBook-Pro:backend2 a$ perl6 --stagestats --target=jvm
> > > --output=guess.jar guess.p6
> > >
> > > Stage start : 0.000
> > >
> > > Stage parse : 3.405
> > >
> > > Stage syntaxcheck: 0.001
> > >
> > > Stage ast: 0.001
> > >
> > > Stage optimize : 0.140
> > >
> > > Stage jast : 0.395
> > >
> > > Stage classfile : 0.081
> > >
> > > Stage jar: 0.000
> > >
> > > Stage jvm: 0.006
> > >
> > > ===SORRY!===
> > >
> > > java.lang.NullPointerException
> > >
> > > Felipes-MacBook-Pro:backend2 a$
> >
> >
> >
The feature you're asking for does not exist at the moment.
You can get the precompiled compilation unit of a Perl 6 program as a .jar with
C<--target=jar>, but that doesn't help you, because it a compilation unit that
can be understood by a Rakudo executable, not a jar file that can be understood
by any JVM.
The file at [1] is a shell script that includes the step that will eventually
be integrated into the perl6 binary to generate a self-contained jar file from
Perl 6 code, albeit in the simplest way possible. That is, bundle the whole
interpreter and make that run a predefined compilation unit. There is a
corresponding Rakudo branch
Note though that the branch hasn't been updated in quite a while and might not
necessarily merge cleanly against current HEAD.
[1] https://github.com/perl6/nqp/blob/standalone-jar/tools/jvm/one-jar-script.sh
[perl #132104] [JVM] EvalServer leaks threads and memory when using Proc::Async
On Thu, 12 Oct 2017 13:35:27 -0700, barto...@gmx.de wrote:
> On Sat, 23 Sep 2017 12:28:53 -0700, barto...@gmx.de wrote:
> > 3) Feeding the EvalServer with a program that calls 'run' (or
> > Proc::Async directly) does heavily leak memory, threads and what not
> > (again assuming a clean EvalServer instance started as above):
> >
> > $ echo 'run("echo", "42");' > foo.p6
> > $ for i in {1..500}; do ./eval-client.pl TESTTOKEN run foo.p6; done
>
> I'm still trying to find the cause of the memory leak. Part of the
> problem seems to be that with each invokation of './eval-client.pl
> TESTTOKEN run foo.p6' three or four additional threads are started.
> Those threads are never stopped.
>
> Some debug statements in src/core/ThreadPoolScheduler.pm indicate that
> with each invokation (s.a.) a new AffinityWorker instance and a new
> GeneralWorker instance are created (and at least one other thread). I
> guess those newly started Threads stay around until the EvalServer is
> killed.
I've pushed some improvements for this issue in NQP commit b88de49aad. As the
commit message notes, there's probably more out there, but this gets us through
spectest on hack.p6c.org at least, with a max RES of around 4.5gb.
[perl #132104] [JVM] EvalServer leaks threads and memory when using Proc::Async
On Thu, 12 Oct 2017 13:35:27 -0700, barto...@gmx.de wrote:
> On Sat, 23 Sep 2017 12:28:53 -0700, barto...@gmx.de wrote:
> > 3) Feeding the EvalServer with a program that calls 'run' (or
> > Proc::Async directly) does heavily leak memory, threads and what not
> > (again assuming a clean EvalServer instance started as above):
> >
> > $ echo 'run("echo", "42");' > foo.p6
> > $ for i in {1..500}; do ./eval-client.pl TESTTOKEN run foo.p6; done
>
> I'm still trying to find the cause of the memory leak. Part of the
> problem seems to be that with each invokation of './eval-client.pl
> TESTTOKEN run foo.p6' three or four additional threads are started.
> Those threads are never stopped.
>
> Some debug statements in src/core/ThreadPoolScheduler.pm indicate that
> with each invokation (s.a.) a new AffinityWorker instance and a new
> GeneralWorker instance are created (and at least one other thread). I
> guess those newly started Threads stay around until the EvalServer is
> killed.
I've pushed some improvements for this issue in NQP commit b88de49aad. As the
commit message notes, there's probably more out there, but this gets us through
spectest on hack.p6c.org at least, with a max RES of around 4.5gb.
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo } }.new.bar'
> > (Mu)
>
> As far as I understand, the problem is deep in nqp-j -- either in
> bind_attribute_boxed (called here:
> https://github.com/perl6/nqp/blob/7479ce662d6313c303cd684ebbbd56559cb82da3/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2913
> ) or in get_attribute_boxed. The code for those methods is far above
> my paygrade.
As of Rakudo commit a9a9e1c97 neither t/spec/S03-metaops/zip.t nor the examples
in this ticket actually using Z fail. The code snippet showing the conversion
of nqp::null to Mu has not changed behavior, but considering this ticket is
about zip and not NQP difference between moar and jvm I am not sure that
qualifies as a reason to keep it open, and I'd request closing.
[perl #130532] [JVM] Failing tests for itemization of arguments with infix: after introduction of Rakudo::Internals.OneValueIterator
On Sat, 14 Jan 2017 13:46:47 -0800, barto...@gmx.de wrote:
> On Tue, 10 Jan 2017 12:46:48 -0800, barto...@gmx.de wrote:
> > I managed to golf this a bit:
> >
> > $ ./perl6-j -e 'use nqp; class A { has Mu $!foo; method bar () {
> > $!foo
> > := nqp::null; say nqp::isnull($!foo) ?? "null" !! $!foo } }.new.bar'
> > (Mu)
>
> As far as I understand, the problem is deep in nqp-j -- either in
> bind_attribute_boxed (called here:
> https://github.com/perl6/nqp/blob/7479ce662d6313c303cd684ebbbd56559cb82da3/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2913
> ) or in get_attribute_boxed. The code for those methods is far above
> my paygrade.
As of Rakudo commit a9a9e1c97 neither t/spec/S03-metaops/zip.t nor the examples
in this ticket actually using Z fail. The code snippet showing the conversion
of nqp::null to Mu has not changed behavior, but considering this ticket is
about zip and not NQP difference between moar and jvm I am not sure that
qualifies as a reason to keep it open, and I'd request closing.
[perl #126702] [JVM] failing test in S06-multi/subsignature.t: wrong multi candidate called when slurpy and named are passed
On Sat, 21 Nov 2015 06:12:07 -0800, barto...@gmx.de wrote:
> The following code does not give the expected result ('2') on
> rakudo.jvm:
>
> $ perl6-j -e 'multi catch(| (*@all ) ) { 1 }; multi catch(| (*@all,
> :$really! ) ) { 2 }; say catch(0, 5, :!really)'
> 1
Neither the mentioned test file nor the specific code example seem to fail on
current Rakudo as well as the currently availabe camelia build (which is
a92950fb4). With confirmation I'd request closing this ticket, as it refers to
existing tests that used to fail but don't anymore.
