[perl #131705] constant Regex: getlex: outer index out of range

[via RT]

# New Ticket Created by  Lloyd Fournier 
# Please include the string:  [perl #131705]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131705 >


echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6

perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];

# getlex: outer index out of range

This is another compile time outer lexical scope bug. Note: the array is
superfluous, just there to avoid triggering RT #131704.

[perl #131704] Can't use unknown trait 'is export' in a regex declaration

[via RT]

# New Ticket Created by  Lloyd Fournier 
# Please include the string:  [perl #131704]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131704 >


perl6 -e 'constant $foo is export = /foo/;'

 seems to be being called on the regex rather than the variable??

[perl #131703] [IO] [REGRESSION] Command line arguments try and open as a file

[via RT]

# New Ticket Created by  Samantha McVey 
# Please include the string:  [perl #131703]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131703 >


Here is the offending code
https://gist.github.com/9ed8322b4c9e1a40e1f3df495d8cee1d (not written by
me).

If you run it normally with no arguments and just press enter till the
end of execution, there are no issues. If you run `perl6 deckofpain.p6
easy` at the end of execution you get


Failed to open file /home/samantha/proj/perl6/easy: No such file or
directory
  in sub MAIN at deck-of-pain.p6 line 127
  in block  at deck-of-pain.p6 line 30


This is the commit that introduced this regression:

[io grant] Swap IO::ArgFiles to IO::CatHandle impl

https://github.com/rakudo/rakudo/commit/f539a624043f5796fcefcca83412ee1ab66e0c4d

[perl #131700] [IO] prompt not working on bash-on-ubuntu on win10

[via RT]

# New Ticket Created by  gfw blackcat 
# Please include the string:  [perl #131700]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131700 >


In bash on win10

Code:

perl6 --ll-exception -e ' prompt "123" '

Output:

123
Cannot flush handle: Failed to flush filehandle: Input/output error
   at SETTING::src/core/Exception.pm:63
(/usr/share/perl6/runtime/CORE.setting.moarvm:throw)
 from SETTING::src/core/Failure.pm:44
(/usr/share/perl6/runtime/CORE.setting.moarvm:throw)
 from SETTING::src/core/Failure.pm:86
(/usr/share/perl6/runtime/CORE.setting.moarvm:sink)
 from SETTING::src/core/io_operators.pm:89
(/usr/share/perl6/runtime/CORE.setting.moarvm:prompt)
 from SETTING::src/core/io_operators.pm:83
(/usr/share/perl6/runtime/CORE.setting.moarvm:prompt)
 from -e:1  (:)
 from -e:1  (:)
 from gen/moar/stage2/NQPHLL.nqp:1589
(/usr/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1696  (/usr/share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:1731
(/usr/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42
(/usr/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1677
(/usr/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/main.nqp:47  (/usr/share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/main.nqp:38
(/usr/share/perl6/runtime/perl6.moarvm:)
 from :1  (/usr/share/perl6/runtime/perl6.moarvm:)
 from :1  (/usr/share/perl6/runtime/perl6.moarvm:)

perl6 -v output:

This is Rakudo version 2017.06 built on MoarVM version 2017.06
implementing Perl 6.c.

[perl #130366] BagHash/MixHash values don't check for zeroness

[Aleks-Daniel Jakimenko-Aleksejev via RT]

This was resolved together with
https://rt.perl.org/Ticket/Display.html?id=131241

Tests needed, maybe. See other ticket for info on this.
On 2016-12-17 01:42:04, elizabeth wrote:
> $ 6 'my $b = .BagHash; $_-- for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; .value-- for $b.pairs; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>1,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> $ 6 'my $b = .BagHash; $_ = 0 for $b.values; dd $b'
> BagHash $b = ("a"=>0,"c"=>0,"b"=>0,"e"=>0,"f"=>0,"d"=>0).BagHash
> *SHOULD* be BagHash $b = ("b"=>1).BagHash
>
>
> Same for MixHash. Baggy/Mixy need to have the equivalent logic to
> ISINSET from SetHash.
>
>
> RTing this so it won’t fall through the cracks.

[perl #131137] Throw out TAP.pm from core

[Zoffix Znet via RT]

Done in 
https://github.com/rakudo/rakudo/commit/ae891f93676fdf412c7e8fa517f5bda2bd6a41d6

[perl #131695] [LTA] Confusion in precedence with <<$foo>>[0]

[Larry Wall via RT]

We now warn on the ambiguity of >> or » when used where it could easily be 
intended as either a hyper or the quotewords terminator.  While we could, in 
theory, do some lookahead to try to suppress this warning in some cases, it 
will be brittle in the face of languages that mutate the postfix space, so I 
think it's better to just warn outright and let people disambiguate with 
whitespace or a suitable change to the hyper or quote delims.

(As for retargeting this ticket to the more general case of multiline quote 
errors, please note that a runaway hyper is not a kind of quote, and that we 
already warning on runaway quotes that cross line boundaries.  Also, the 
problem here is essentially independent of multi-line-ness.  So I've changed 
the title of this bug back to the original, since that's the problem we're 
fixing.)

[perl #131699] [LTA] Errors indexing past the end of a List

[Zoffix Znet via RT]

On Tue, 04 Jul 2017 07:20:50 -0700, elizabeth wrote:
> > Hm. Wouldn't that make behavior of Lists and Arrays different?
> 
> No, because Lists are supposed to be immutable wrt to the number of
> elements.

Yes, but that doesn't mean the user of the list necessarily knows or has to 
know how many elements the list has, to look up an element by index, without 
things exploding.

> generate a Failure on out of bounds value

IMO that's the wrong approach and the current behaviour of returning Nil is 
most desirable. Consider this code:

sub do-stuff (@args) {
say @args[0] + 1;
}

do-stuff [];
do-stuff ();

If you Fatalise past-end .AT-POS on Lists that sub will now work fine with 
Arrays, but crash with Lists. So as a consumer of `@args` Iterable, I'm now 
faced with two potential behaviours and have to account for Exceptions.

Currently, the code will also produce a warning, as do many things that consume 
a Nil where Nil doesn't really belong. IMO that's a good-enough warning for the 
inadvertent out-of-bounds access.

By adding the Failure, we also end up with another inconsistency that `my ($a, 
$b) = @list` would work and assign Nil to `$b` when `@list` has just one 
element, but `my ($a, $b) = @list[0,1]` would assign a Failure to it. Lastly, 
we'd have `@list[0,1]` return a list with 1 value and 1 Failure in it (call 
.elems on it and the Failure's silently gone).

So, IMO, yes, we could change "0..^Inf" to tell number of actual elements, but 
that error is fundamentally different from trying to access past List's end, 
because you can NEVER access element at index -1, yet you can access index N, 
and we should leave the "return Nil" behaviour as is and not deviate from Array 
behaviour.

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen]

> On 4 Jul 2017, at 16:19, Elizabeth Mattijsen  wrote:
> That said, a List may not always be completely reified already.  So 
> logically, a List may  have 100 elements, it could well be that only 42 of 
> these elements exist already.  Which means that the underlying NQP array, 
> which *is* mutable, only has 42 elements.  But it cannot know offhand whether 
> those are all possible elements, as that depends on the iterator that is 
> being used to fill the NQP array.
> 
> A complicating factor is that this is a very hot code path, so any changes 
> there could affect general performance significantly.  My initial tests to 
> generate a Failure on out of bounds value immediately results in 2 internal 
> errors trying to generate backtrace  :-(
> 
> Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
> it so without making everything significantly slower.
> 
> FWIW, the code in question lives around line 480 in List.pm.

An example of a List that will never be fully reified:

  $ 6 'my $l = ^Inf .list; dd $l.^name; dd $l[10]'
  "List"
  10


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen via RT]

> On 4 Jul 2017, at 16:05, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> On 2017-07-04 05:29:20, comdog wrote:
>> Accessing a List element beyond the end of the List returns Nil,
>> although accessing an element before the beginning returns an out of
>> bounds failure. I think there's two things that can be better here
>> since we know the size of the List.
>> 
>> my $list = < a b c >;
>> put "I have a {$list.^name}";
>> 
>> First, in the "before" case, we have more information than the error
>> message lets on. The index should be from 0 to 2:
>> 
>> {
>> my $i = -1;
>> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
>> }
>> 
>> But this requires the change I think is more helpful. Since the List
>> size won't change, we can have the same out-of-bounds error on
>> accesses past the end. At the moment it's no warning:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i]; # No warning
>> }
>> 
>> This would then be the error for assigning into a position beyond the
>> end. The existing error doesn't say what went wrong even though Perl 6
>> has enough information to figure that out:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i] = 5; # Cannot modify an immutable Nil
>> }
> Hm. Wouldn't that make behavior of Lists and Arrays different?

No, because Lists are supposed to be immutable wrt to the number of elements.

That said, a List may not always be completely reified already.  So logically, 
a List may  have 100 elements, it could well be that only 42 of these elements 
exist already.  Which means that the underlying NQP array, which *is* mutable, 
only has 42 elements.  But it cannot know offhand whether those are all 
possible elements, as that depends on the iterator that is being used to fill 
the NQP array.

A complicating factor is that this is a very hot code path, so any changes 
there could affect general performance significantly.  My initial tests to 
generate a Failure on out of bounds value immediately results in 2 internal 
errors trying to generate backtrace  :-(

Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
it so without making everything significantly slower.

FWIW, the code in question lives around line 480 in List.pm.


Liz

Re: [perl #131699] [LTA] Errors indexing past the end of a List

[Elizabeth Mattijsen]

> On 4 Jul 2017, at 16:05, Aleks-Daniel Jakimenko-Aleksejev via RT 
>  wrote:
> On 2017-07-04 05:29:20, comdog wrote:
>> Accessing a List element beyond the end of the List returns Nil,
>> although accessing an element before the beginning returns an out of
>> bounds failure. I think there's two things that can be better here
>> since we know the size of the List.
>> 
>> my $list = < a b c >;
>> put "I have a {$list.^name}";
>> 
>> First, in the "before" case, we have more information than the error
>> message lets on. The index should be from 0 to 2:
>> 
>> {
>> my $i = -1;
>> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
>> }
>> 
>> But this requires the change I think is more helpful. Since the List
>> size won't change, we can have the same out-of-bounds error on
>> accesses past the end. At the moment it's no warning:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i]; # No warning
>> }
>> 
>> This would then be the error for assigning into a position beyond the
>> end. The existing error doesn't say what went wrong even though Perl 6
>> has enough information to figure that out:
>> 
>> {
>> my $i = $list.end + 1;
>> $list[$i] = 5; # Cannot modify an immutable Nil
>> }
> Hm. Wouldn't that make behavior of Lists and Arrays different?

No, because Lists are supposed to be immutable wrt to the number of elements.

That said, a List may not always be completely reified already.  So logically, 
a List may  have 100 elements, it could well be that only 42 of these elements 
exist already.  Which means that the underlying NQP array, which *is* mutable, 
only has 42 elements.  But it cannot know offhand whether those are all 
possible elements, as that depends on the iterator that is being used to fill 
the NQP array.

A complicating factor is that this is a very hot code path, so any changes 
there could affect general performance significantly.  My initial tests to 
generate a Failure on out of bounds value immediately results in 2 internal 
errors trying to generate backtrace  :-(

Anyways, I agree with brian’s feelings on this.  The challenge is now to make 
it so without making everything significantly slower.

FWIW, the code in question lives around line 480 in List.pm.


Liz

[perl #131699] [LTA] Errors indexing past the end of a List

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Hm. Wouldn't that make behavior of Lists and Arrays different?

On 2017-07-04 05:29:20, comdog wrote:
> Accessing a List element beyond the end of the List returns Nil,
> although accessing an element before the beginning returns an out of
> bounds failure. I think there's two things that can be better here
> since we know the size of the List.
>
> my $list = < a b c >;
> put "I have a {$list.^name}";
>
> First, in the "before" case, we have more information than the error
> message lets on. The index should be from 0 to 2:
>
> {
> my $i = -1;
> $list[$i]; # Index out of range. Is: -1, should be in 0..^Inf
> }
>
> But this requires the change I think is more helpful. Since the List
> size won't change, we can have the same out-of-bounds error on
> accesses past the end. At the moment it's no warning:
>
> {
> my $i = $list.end + 1;
> $list[$i]; # No warning
> }
>
> This would then be the error for assigning into a position beyond the
> end. The existing error doesn't say what went wrong even though Perl 6
> has enough information to figure that out:
>
> {
> my $i = $list.end + 1;
> $list[$i] = 5; # Cannot modify an immutable Nil
> }

[perl #131699] [LTA] Errors indexing past the end of a List

[brian d foy]

# New Ticket Created by  "brian d foy" 
# Please include the string:  [perl #131699]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131699 >


Accessing a List element beyond the end of the List returns Nil,
although accessing an element before the beginning returns an out of
bounds failure. I think there's two things that can be better here
since we know the size of the List.

my $list = < a b c >;
put "I have a {$list.^name}";

First, in the "before" case, we have more information than the error
message lets on. The index should be from 0 to 2:

{
my $i = -1;
$list[$i];  # Index out of range. Is: -1, should be in 0..^Inf
}

But this requires the change I think is more helpful. Since the List
size won't change, we can have the same out-of-bounds error on
accesses past the end. At the moment it's no warning:

{
my $i = $list.end + 1;
$list[$i]; # No warning
}

This would then be the error for assigning into a position beyond the
end. The existing error doesn't say what went wrong even though Perl 6
has enough information to figure that out:

{
my $i = $list.end + 1;
$list[$i] = 5;  # Cannot modify an immutable Nil
}