[perl #133268] MoarVM with empty CONTROL {}

[brian d foy]

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


While running this program I get a MoarVM panic:

2 + 2 = 4
'two' is not numeric
MoarVM panic: Trying to unwind over wrong handler

The program:

sub add-two-things ( $first, $second ) {
CATCH {
when X::Str::Numeric {
fail q/One of the arguments wasn't a number/
}
}

for $first, $second {
warn "'$_' is not numeric"  unless val($_) ~~ Numeric;
}

return $first + $second;
}

my @items = < 2 2 3 two nine ten 1 37 0 0 >;

for @items -> $first, $second {
CONTROL {}
my $sum = add-two-things( $first, $second );

put $sum.defined ??
"$first + $second = $sum" !!
"You can't add $first and $second";
}

-- 
brian d foy 
http://www.pair.com/~comdog/

Re: [perl #133057] Odd interaction of HTTP::UserAgent and Promises

[brian d foy]

The error message isn't useful because you get that no matter what
happens. It's really the IO::Socket::SSL is not thread safe.

But, I'd not expect a segfault.

Re: [perl #133057] Odd interaction of HTTP::UserAgent and Promises

[brian d foy via RT]

The error message isn't useful because you get that no matter what
happens. It's really the IO::Socket::SSL is not thread safe.

But, I'd not expect a segfault.

Re: [perl #133057] AutoReply: Odd interaction of HTTP::UserAgent and Promises

[brian d foy via RT]

Ah, there's even an HTTP::UserAgent issue for this I think:
https://github.com/sergot/http-useragent/issues/191

Re: [perl #133057] AutoReply: Odd interaction of HTTP::UserAgent and Promises

[brian d foy]

Ah, there's even an HTTP::UserAgent issue for this I think:
https://github.com/sergot/http-useragent/issues/191

[perl #133057] Odd interaction of HTTP::UserAgent and Promises

[brian d foy]

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


I have this little program where I want to fetch web thingys
concurrently. There's a problem with the combination of HTTP::UserAgent
and Promises although I don't know which one doesn't work:

#!perl6

use HTTP::UserAgent;
my $ua = HTTP::UserAgent.new: :useragent;

my @urls = <
http://www.perl.org
http://www.perl6.org
http://www.yahoo.com
>;

loop {
my @promises;
for @urls -> $url {
@promises.push: Promise
.start({ $ua.get: $url })
.then({ put "Got {.result.^name}" });
}
await @promises;
}

Running this program sometimes works a little and often if fails in
diverse and curious ways. I couldn't get it to fail unless I used a
Promise:

$ perl6 cycle.p6
Got HTTP::Response
Segmentation fault: 11

$ perl6 cycle.p6
Got HTTP::Response
Illegal instruction: 4

$ perl6 cycle.p6
Got HTTP::Response
An operation first awaited:
  in block  at cycle.p6 line 20

Died with the exception:
Tried to get the result of a broken Promise
  in block  at cycle.p6 line 18

Original exception:
Please install IO::Socket::SSL in order to fetch https
sites: Failed to seek in filehandle: 22
  in method get-connection at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 350
  in method get-connection at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 343
  in method request at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 156
  in method request at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 176
  in method get at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 102
  in method get at
/Users/brian/Desktop/lib/HTTP/UserAgent.pm (HTTP::UserAgent) line 105
  in block  at cycle.p6 line 17

$ perl6 cycle.p6
Got HTTP::Response
moar(77217,0x70001052c000) malloc: *** error for object
0x7fd7b89a4af0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Here's the setup

$ perl6 -v
This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
implementing Perl 6.c.
$ uname -a
Darwin . 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54
PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64

[perl #132980] Coercion type apparently does not check the actual type of the coerced value

[brian d foy]

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


I was playing with coercion types and wondered what would happen if
a .Int method did not return the right sort of type:

class Foo {
method Int ( --> Str ) { 'Hello' }
}

put try-it( Foo.new );

sub try-it ( Int() $n ) { "Got <$n> of type <{$n.^name}>" }

Although the subroutine signature demanded an Int, it accepted
something that claimed to be able to convert but actually didn't:

Got  of type 

I would have expected the runtime constraint to check the ultimate
value against the type and this would have failed.


-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

Re: [perl #132885] AutoReply: .next-handle seems to change handles but doesn't

[brian d foy via RT]

I can fix this by closing the old file handle and checking the new
one, but that seems like way to much work at the user level.

quietly {
my $limit = 5;
for lines() {
state $lines = 1;
FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 } }
if $lines > $limit {
$*ARGFILES.next-handle.close;
last unless $*ARGFILES.opened;
next;
}
put "{$*ARGFILES.path}:{$lines++} $_";
}
}

Re: [perl #132885] AutoReply: .next-handle seems to change handles but doesn't

[brian d foy]

I can fix this by closing the old file handle and checking the new
one, but that seems like way to much work at the user level.

quietly {
my $limit = 5;
for lines() {
state $lines = 1;
FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 } }
if $lines > $limit {
$*ARGFILES.next-handle.close;
last unless $*ARGFILES.opened;
next;
}
put "{$*ARGFILES.path}:{$lines++} $_";
}
}

[perl #132885] .next-handle seems to change handles but doesn't

[brian d foy]

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


#!/Users/brian/bin/perl6s/perl6-latest

I'm playing with .next-handle from IO::CatHandle. I'm
trying to create a situation where I can read just the first five
lines from each command line argument:

quietly {
my $limit = 5;
for lines() {
state $lines = 1;
FIRST { $*ARGFILES.on-switch = { put "NEW FILE"; $lines = 1 } }
if $lines > $limit {
$*ARGFILES.next-handle;
next;
}
put "{$*ARGFILES.path}:{$lines++} $_";
}
}

Here's a test file:

First
Second
Third
Fourth
Fifth
Six
Seventh

With one or more command-line arguments I get this odd behavior (and
lots of warnings that I suppressed):

test.txt:1 First
test.txt:2 Second
test.txt:3 Third
test.txt:4 Fourth
test.txt:5 Fifth
NEW FILE
:1 Seventh
read bytes requires an object with REPR MVMOSHandle (got VMNull
with REPR Null)
  in block  at lines-method.p6 line 5

It does "switch" after five lines, but then it keeps reading from the
same handle while losing a line. Then there's a strange error at the
end that kills the whole thing.

I expected that it would close the current handle, open a new one, and
continue. If it gets to the end, it would simply not provide any more
lines() and things would end normally.

The docs for .next-handle lets you keep changing it as long as you
like no matter how many

-

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

[perl #132874] writing to utf16 handle gives write_fhb error

[brian d foy]

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


This little program:

my $fh = open 'test.txt', :w, :enc('utf16');
put "filehandle is using {$fh.encoding}";
$fh.put: 'Some text';

Gives this error:

filehandle is using utf16
write_fhb requires a native array of uint8 or int8


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

[perl #132713] Order of `is assoc` and precedence traits matter, but should it?

[brian d foy]

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


I originally asked this on StackOverflow:

https://stackoverflow.com/q/48219788/2766176

This fails to be right associative:

sub infix:<↑> ( Int:D \n, Int:D \m  --> Int:D )
is assoc
is equiv(:<**>)
{ n ** m }

put "2**2**2**2 = ",  2**2**2**2;
put "2↑2↑2↑2 = ", 2↑2↑2↑2;
put "2↑ (2↑ (2↑2) ) = ",  2↑ (2↑ (2↑2) );

Reversing the traits fixes that:

sub infix:<↑> ( Int:D \n, Int:D \m  --> Int:D )
is equiv(:<**>)
is assoc
{ n ** m }

I didn't see anything in the docs about the ordering of traits but
I wouldn't expect order to matter. Neither did I see anything saying I
couldn't combine traits.

As far as I can tell the precedence still works when it's specified first:

sub infix:<↑> ( Int:D \n, Int:D \m  --> Int:D )
is equiv(:<**>)
is assoc
{ n ** m }

put "2↑3**4↑2 = ", 2↑2**2↑2;
put "2↑(3**(4↑2)) = ", 2↑2**2↑2;


put "2↑3*4↑2 = ", 2↑2*2↑2;
put "(2↑2)*(2↑2) = ",(2↑2)*(2↑2);


put "2↑3+4↑2 = ", 2↑2+2↑2;
put "(2↑2)+(2↑2) = ", (2↑2)+(2↑2);

How is this supposed to work? Should either way work? I can easily
imagine situations where I want to stack many traits:

sub infix:<↑>  ( Int:D \n, Int:D \m  --> Int:D )
is equiv(:<**>)
is assoc
is pure
is export
{ ... }

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[brian d foy]

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


I stupidly did this:

sub prefix:<²>  ( Int:D \m --> Int:D )
is assoc
{ m ** m }

put ²(²2);

And got this error:

===SORRY!===
MVMArray: Can't pop from an empty array

I figure that associativity doesn't make any sense for unary prefix
operators but that error message is from pretty deep in the swamp. I'd
rather have something like "Don't do stupid things that make no sense"
sort of error.

[perl #132710] [LTA] Warning message for duplicated tighter trait

[brian d foy]

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


I was playing with higher orders of multiplication and defining some
operators for them. When I try to make one of my new operators tighter
than one I've already defined:

multi infix:<↑> ( Int:D $n, Int:D $m  --> Int:D )
is assoc
is tighter(:<**>)
{ $n ** $m }

multi infix:<↑↑> ( Int:D $, 0 --> Int:D )
is assoc
is tighter(:<↑>)
{ 1 }

multi infix:<↑↑> ( Int:D $n, Int:D $m  --> Int:D )
is assoc
is tighter(:<↑>)
{ [↑] $n xx $m }

put 2 ↑  3;  # 2  * 2  * 2 =  8
put 2 ↑↑ 3;  # 2 ** 2 ** 2 = 16

This gets the odd error about something that's not part of my code:

===SORRY!=== Error while compiling /Users/brian/Desktop/knuth2.p6.pl
No such method 'subst' for invocant of type 'Any'

The problem turns out to be my duplication of the tighter. That's
better left to a proto definition instead of the candidates. I know
that now but the error message could have helped with that.

-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

[perl #132549] Can't put() any(): This type cannot unbox to a native string

[brian d foy]

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


This comes from an answer to a Perl 6 question on Stackoverflow that
showed a different bug:

https://stackoverflow.com/q/45527881/2766176

With put() it does not and gives a strange error:

$ perl6 -e 'put any( 1, 3, 7 ) '
This type cannot unbox to a native string: P6opaque, Junction
  in block  at -e line 1

$ perl6 -e 'put( any( 1, 3, 7 )  )'
This type cannot unbox to a native string: P6opaque, Junction
  in block  at -e line 1

With say it has no problem:

$ perl6 -e 'say any( 1, 3, 7 )'
any(1, 3, 7)
$ perl6 -e 'put any( 1, 3, 7 ).gist'
any(1, 3, 7)

I'd expect anything that can .gist would be able to .Str.

This is Rakudo 2017.10 on macOS 10.13.

[perl #132543] Can't tail a tail.

[brian d foy]

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


I first asked about this on Stackoverflow:

https://stackoverflow.com/q/47704428/2766176

A .tail on a .tail appears to do the wrong thing:

> my $list = ;
(a b c d e f g h i j)

> $list.tail(5).tail
Nil

But throwing a list in there works:

> $list.tail(5).list.tail
j

Timo said:

.tail and .tail(1) are implemented with
Rakudo::Iterator.LastValue and
Rakudo::Iterator.LastNValues respectively, which differ
quite a bit in implementation.

https://github.com/rakudo/rakudo/blob/master/src/core/Rakudo/Iterator.pm#L1807

And he figures:

tail on the List takes an iterator and skips it ahead $n
items. then, the tail method on Seq calls count-only on
it to figure out how far to skip ahead to get the last
$m items. However, count-only on the first iterator just
gives you the total number of items in the original
list. It should probably either signal an error when
asked for count-only, or it should calculate the proper
amount of items left.

[perl #132511] Binary assignment Z+= fails if it's the last thing in for loop

[brian d foy]

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


I previously asked about this unexpected Z behavior on Stackoverflow
( https://stackoverflow.com/q/45001820/2766176 ).

I expected this to change several hash keys at once. It changes no keys:

my $hash = %(
wallet   => 100,
gave =>   0,
received =>   0,
);

for ^1 { $hash Z+= <-1 1> }

dd $hash;

I get:

Hash $hash = ${:gave(0), :received(0), :wallet(100)}

If I change that to add another statement it works:

for ^1 { $hash Z+= <-1 1>; True }

It also works if I take out the binary assignment:

for ^1 { $hash = $hash Z+ <-1 1> }

[perl #132510] "problem while trying to set up Linenoise"

[brian d foy]

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


I did a fresh install of 2017.10 on macOS High Sierra. Immediately
started the REPL and got this message:

---
I ran into a problem while trying to set up Linenoise:
'/Applications/Rakudo/share/perl6/site/short/0008C6C3077BB1943C736587EB1404E59CD84E70'
is a directory, cannot do '.open' on a directory
Continuing without tab completions or line editor
You may want to consider using rlwrap for simple line editor functionality

To exit type 'exit' or '^D'
> $*VM
moar (2017.10)

[perl #132179] Don't put Mexico and Texas in opposition in Perl 6 jargon

[brian d foy]

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


And, that's not bake any other geopolitical oppositions into the
language either. The Texas metaphor was a joke about that an American
stereotype and you shouldn't go further with it.

https://rt.perl.org/Public/Bug/Display.html?id=132176

Re: [perl #131922] [LTA] "Variadic" or "slurpy"?

[brian d foy via RT]

Several areas of the docs then need to correct that. No matter what you
decide, a user should be able to take the tricky words in an error message
and usefully find them in the docs.


-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

Re: [perl #131922] [LTA] "Variadic" or "slurpy"?

[brian d foy]

Several areas of the docs then need to correct that. No matter what you
decide, a user should be able to take the tricky words in an error message
and usefully find them in the docs.


-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

[perl #131922] [LTA] "Variadic" or "slurpy"?

[brian d foy]

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


Consider this program which I don't expect to work (and it doesn't compile):

sub show-the-arguments ( *@args, $i ) {
put "The arguments are @args[]";
}

show-the-arguments( 1, 3, 7 );

The error message says "variadic":

Cannot put required parameter $i after variadic parameters

But another sort of error uses a different term:

sub show-the-arguments ( *@args, $i ) {
put "The arguments are @args[]";
}

This time the error messages say "slurpy":

Only one slurpy positional allowed

The docs almost almost always say "slurpy" and the uses of "variadic"
only appear as synonyms next to "slurpy":

* https://github.com/perl6/doc/search?utf8=✓=variadic=

* https://github.com/perl6/doc/search?utf8=✓=slurpy=

[perl #131776] perl6-debug-m can't setlang on object of type Perl6::HookGrammar

[brian d foy]

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


When I run perl6-debug-m from the Rakudo Star, I get this error:

$ perl6-debug-m test.p6
Cannot find method 'setlang' on object of type Perl6::HookGrammar
   at gen/moar/perl6-debug.nqp:407
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:comp_unit)
 from src/Perl6/Grammar.nqp:492
(/Applications/Rakudo/share/nqp/lib/Perl6/Grammar.moarvm:TOP)
 from gen/moar/stage2/QRegex.nqp:2315
(/Applications/Rakudo/share/nqp/lib/QRegex.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:1895
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:1836
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:run)
 from gen/moar/stage2/NQPHLL.nqp:1846
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:1824
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:compile)
 from gen/moar/stage2/NQPHLL.nqp:1570
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/perl6-debug.nqp:449
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1791
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:1685
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42
(/Applications/Rakudo/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1659
(/Applications/Rakudo/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/perl6-debug.nqp:511
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:MAIN)
 from gen/moar/perl6-debug.nqp:442
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:)
 from :1
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:)
 from :1
(/Applications/Rakudo/share/perl6/runtime/perl6-debug.moarvm:)

I'm using:

$ perl6 -v
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.

[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
}

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

[brian d foy via RT]

On Mon, Jul 3, 2017 at 11:09 AM, jn...@jnthn.net via RT
 wrote:

> I can see the potential for a human reader to be confused,

I think there are two improvements here:

* a better explanation of interpolation and what's allowed there (such
as "only postfix...") with plenty of examples.

* a better explanation of the process. I wouldn't have expected
something to eat that much inside the string. Not everything in the
main language is going to interpolate, so how is it making its
decision which thing it wants to parse?

* perhaps a better error message. We know we are inside a quoting
thing, so we might be able to guess that the quoting thing is not
terminated.

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

[brian d foy]

On Mon, Jul 3, 2017 at 11:09 AM, jn...@jnthn.net via RT
 wrote:

> I can see the potential for a human reader to be confused,

I think there are two improvements here:

* a better explanation of interpolation and what's allowed there (such
as "only postfix...") with plenty of examples.

* a better explanation of the process. I wouldn't have expected
something to eat that much inside the string. Not everything in the
main language is going to interpolate, so how is it making its
decision which thing it wants to parse?

* perhaps a better error message. We know we are inside a quoting
thing, so we might be able to guess that the quoting thing is not
terminated.

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

[brian d foy]

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


It seems that term precedence with << >> gets confused.

I also asked this on StackOverflow: https://stackoverflow.com/q/44872419/2766176

my $string = '5+8i';

{
my $number = val $string;
put "Type: " ~ $number.^name;
put "Elems: " ~ $number.elems;
put "First: " ~ $number.[0];
}

{
my $number = <<$string>>;
put "Type: " ~ $number.^name;
put "Elems: " ~ $number.elems;
put "First: " ~ $number.[0];
}

{
my $number = <<$string>>[0];
put "Type: " ~ $number;
#`(
===SORRY!=== Error while compiling ...
Cannot use variable $number in declaration to initialize itself
--> put "Type: " ~ $⏏number;
expecting any of:
double quotes
statement end
statement modifier
statement modifier loop
term
)
}

[perl #131408] Curious "Too many positionals" error from bail-out() with no positionals.

[brian d foy]

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


I have this program:

#!/Applications/Rakudo/bin/perl6

use Test;
bail-out();

When I run it, it complains about too many parameters:

$ prove -e 'perl6 -Ilib' t/bail.t
t/bail.t .. Any
Too many positionals passed; expected 1 argument but got 2
  in sub bail-out at
/Applications/Rakudo/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E
(Test) line 258
  in block  at t/bail.t line 4

t/bail.t .. Dubious, test returned 1 (wstat 256, 0x100)
No subtests run

Test Summary Report
---
t/bail.t (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=1, Tests=0,  2 wallclock secs ( 0.03 usr  0.01 sys +  2.14
cusr  0.16 csys =  2.34 CPU)
Result: FAIL

This is the section causing the problem:

256 sub bail-out ($desc?) is export {
257 $output.put: join ' ', 'Bail out!', ( $desc ?? $desc !! '' );
258 $done_testing_has_been_run = 1;
259 exit 255;
260 }

I made several changes to try to suss out the problem, but I couldn't
make the error go away without removing line 257. When I check "$output.^name",
I get "Any".

Running without `prove` shows the same problem:

$ perl6 t/bail.t
Too many positionals passed; expected 1 argument but got 2
  in sub bail-out at
/Applications/Rakudo/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E
(Test) line 257
  in block  at t/bail.t line 4

Running it in https://glot.io/new/perl6 shows the same thing.

Besides the actual error, the error message isn't great. I would have
liked it to mention the method name and class causing the problem.


This is:

$ perl6 -v
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.

Re: [perl #131392] %() creates a Map

[brian d foy via RT]

I did pull my first example out of a slightly larger program I was
playing with, but I thought that a match would surely have no effect.
Stupid me, because I've been around long enough to know that
assumption is almost always false. That "harmless" thing you leave out
is the actual problem. Here's a complete program that reproduces it:

'abcdef' ~~ m/ cd /;

my $thingy = %();
put $thingy.^name;  #Map

Re: [perl #131392] %() creates a Map

[brian d foy]

I did pull my first example out of a slightly larger program I was
playing with, but I thought that a match would surely have no effect.
Stupid me, because I've been around long enough to know that
assumption is almost always false. That "harmless" thing you leave out
is the actual problem. Here's a complete program that reproduces it:

'abcdef' ~~ m/ cd /;

my $thingy = %();
put $thingy.^name;  #Map

[perl #131392] %() creates a Map

[brian d foy]

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


It looks like %() with no characters between the parens creates a
Map, but if there's at least one character between the parens, it
creates a Hash. I figure all of these should create a Hash:

my %hash = %();
put '1: ', %hash.^name;  # 1: Hash

my $hash-empty = %();
put '2: ', $hash-empty.^name;# 2: Map

my $hash-space = %( );
put '3: ', $hash-space.^name;# 3: Hash

Where is %() documented (other than examples using it)?

$ perl6 -v
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.

[perl #131350] Useless 'Useless use' comes out of is tighter

[brian d foy]

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


#`(
When I compile this code, I get the error:

Useless use of constant value [ ] in sink context (lines 9, 9)

I don't think it was useless because it did what I needed.

I really wanted the ᔑ to be tighter then ., but that's not a real
operator and I ccouldn't use it to set precedence.
)

sub prefix:<ᔑ> (Pair $p --> Pair) is tighter(:<[ ]>) {
$p.value
=>
$ = $p.key
}

[perl #131349] .invert returns Seq instead of Pair

[brian d foy]

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


.invert doesn't do what it says on the tin. From
https://docs.perl6.org/type/Pair#method_invert

my Pair $p1 = (6 => 'Perl');
say $p1.invert;   # OUTPUT: «Perl => 6␤»
say $p1.invert.WHAT;  # OUTPUT: «(Pair)␤»

my Pair $p2 = ('Perl' => (5, 6));
say $p2.invert;   # OUTPUT: «(5 =>
Perl 6 => Perl)␤»
say $p2.invert.WHAT;  # OUTPUT: «(List)␤»

my Pair $p3 = ('Perl' => { cool => 'language'});
say $p3.invert;   # OUTPUT: «{cool
=> language => Perl}␤»
say $p3.invert.WHAT;  # OUTPUT: «(Hash)␤»

I get sequences instead:

(Perl => 6)
(Seq)
(5 => Perl 6 => Perl)
(Seq)
((cool => language) => Perl)
(Seq)

% perl6 -v
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.

[perl #131339] Pair.new uses positional parameters despite error message

[brian d foy]

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


I was playing with Pair and found this odd error message that says
the default constructor only takes named arguments. While .new can
take named arguments, it doesn't do anything iwth them. It does
construct a Pair from positional parameters though.

> my @array = 
[a b c]
> :@array
array => [a b c]
> my $pair = Pair.new: @array
Default constructor for 'Pair' only takes named arguments
  in block  at  line 1

> my $pair = Pair.new: :a('b')
(Mu) => (Mu)

[perl #131118] Junctions that can evaluate to True shouldn't blow up for items that won't

[brian d foy]

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


Consider this junction which you probably shouldn't make but you know
will happen in the hands of users:

any( 5, 'flarg' ) == 5

Despite having an element that satisfies the condition, it blows up
because one of them doesn't:

> any(5, "flarg") == 5
Cannot convert string to number: base-10 number must begin with
valid digits or '.' in '⏏flarg' (indicated by ⏏)
  in block  at  line 1

But, it should't matter that what happens with any other parts of the
junction if at least one of them satisfies the condition. You could,
for instance, evaluate that differently so the new junction looks
something like this:

any( True, Failure );

But, I don't think it should evaluate to another junction at all. The
comparison operator should evaluate to a Boolean. That Failure will
never matter because it's equivalent to False.

Re: [perl #131114] Should junctions collapse unique values?

[brian d foy]

I consider it a bug that a Junction does what its doing, and reported
it as such. The combinatorial explosion is something I think should
not happen.

For questions, I use Stackoverflow. However, other people keep telling
me to file bugs. Lots of mixed messages there. Either way, the real
time and social media channels aren't searchable and of little value
to those googling to find answers to similar questions.

[perl #131114] Should junctions collapse unique values?

[brian d foy]

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


# using Rakudo 2017.01

Should junctions only care about unique values?

For example, does 3 need to be in the junction twice?

> my $j = any( 1, 2, 3, 3 )
any(1, 2, 3, 3)

I ran into this when I was playing around with something like
this where I ended up with a junction has the same value repeated:

> $j > 5
any(False, False, False, False)

Curiously, I expected the result would be either True or False
rather than another junction.

Consider how this propagates:

> $j > any( 5, 2 )
any(any(False, False), any(False, False), any(False, True),
any(False, True))

As a boolean value, this is merely a baroque True. Since junctions
are not introspective, it doesn't need to remember how it got there.

[perl #131097] Why doesn't Perl 6's try handle a non-zero exit in shell()?

[brian d foy]

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


I originally asked about this on Stackoverflow
(http://stackoverflow.com/q/43199427/2766176)

This `try` catches the exception:

try die X::AdHoc;
say "Got to the end";

The output shows that the program continues:

 Got to the end

If I attempt it with `shell` and a command that doesn't exit with 0,
the `try` doesn't catch it:

try shell('/usr/bin/false');
say "Got to the end";

The output doesn't look like an exception:

The spawned command '/usr/bin/false' exited unsuccessfully (exit code: 1)
  in block  at ... line ...

What's going on that this makes it through the `try`?

--- Perl variables ---
Perl:   Perl 6
Executable: perl6
Flavor: Rakudo 2017.01
VM: MoarVM 2017.01
Distro: macosx
Kernel: darwin
PERL6LIB:

--- Other Environment ---
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
LC_ALL: en_US.UTF-8
LESSCHARSET: utf-8
LOCALE_I_WANT: en_US.UTF-8
LOCAL_PATH: /usr/local/bin
SHELL: /bin/bash
SHLVL: 1
TERM: vt100

-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

[perl #130920] Tap's closing callback doesn't call back

[brian d foy]

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


This is the example from the Tap docs. I expect the output to be
"Tap closed", but I get no output using 2017.01:

my $s = Supplier.new;
my $tap = $s.Supply.tap(
-> $v { say "the value is $v" },
done=> { say "Supply is done" },
closing => { say "Tap closed" },
quit=> -> $ex { say "Supply finished with error $ex" },
);

# later
$tap.close;

[perl #130919] Supplier.done is only handled by first tap

[brian d foy]

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


The .done method of a Supplier should call all the done handlers in
all the taps that have one. I don't think that's happening in 2017.01.

It looks like only the first .tap gets to the done message:

my $supplier = Supplier.new;
my $supply   = $supplier.Supply;

$supply.tap(
done => { put "1. Done" },
);
$supply.tap(
done => { put "2. Done" },
);

$supplier.done; # output only first

I get just the first handler:

1. Done

And, if the first .tap does not have a done handler, I get no
output:

my $supplier = Supplier.new;
my $supply   = $supplier.Supply;

$supply.tap(
);
$supply.tap(
done => { put "2. Done" },
);

$supplier.done;  # no output

[perl #130845] Some things that are less than 5 aren't

[brian d foy]

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


Here's a curious change over in precision:

> 4.999 ~~ 0..^5
True
> 4. ~~ 0..^5
False

I figure this is an implementation detail that ties to storage, but
one of the selling points of Perl 6 is that this sort of thing isn't
a problem anymore.

> $*PERL
Perl 6 (6.c)
> $*VM
moar (2017.01)

[perl #130781] Using both :out and :err in run() reports the wrong exit code

[brian d foy]

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


Here's a program that starts another program with run() with
various combinations of :out and :err. When :out and :err are both
specified, the exit code is incorrect. This is 2017.01:

#!/Applications/Rakudo/bin/perl6

use v6;

my $filename = 'null-program.p6';
my $fh = open $filename, :w;
END { unlink $filename }

$fh.put( q:to/HERE/ );
#!{ $*EXECUTABLE }
$*ERR.say( Q/This goes to standard error/ );
$*OUT.say( Q/This goes to standard output/ );

exit 137;
HERE

{
my $proc = run $*EXECUTABLE, $filename;
say "1. Exit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :out;
$proc.out.slurp-rest( :close );
say "2. Exit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :err;
$proc.err.slurp-rest( :close );
say "3. EHere's a program that starts another program with run() with
various combinations of :out and :err. When :out and :err are both
specified, the exit code is incorrect:

#!/Applications/Rakudo/bin/perl6

use v6;

my $filename = 'null-program.p6';
my $fh = open $filename, :w;
END { unlink $filename }

$fh.put( q:to/HERE/ );
#!{ $*EXECUTABLE }
$*ERR.say( Q/This goes to standard error/ );
$*OUT.say( Q/This goes to standard output/ );

exit 137;
HERE

{
my $proc = run $*EXECUTABLE, $filename;
say "1. Exit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :out;
$proc.out.slurp-rest( :close );
say "2. Exit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :err;
$proc.err.slurp-rest( :close );
say "3. Exit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :out, :err;
$proc.out.slurp-rest( :close );
$proc.err.slurp-rest( :close );
say "4. Exit is { $proc.exitcode }";
}

The fourth situation reports a different exit code:

This goes to standard error
This goes to standard output
1. Exit is 137
This goes to standard error
2. Exit is 137
This goes to standard output
3. Exit is 137
4. Exit is 0xit is { $proc.exitcode }";
}

{
my $proc = run $*EXECUTABLE, $filename, :out, :err;
$proc.out.slurp-rest( :close );
$proc.err.slurp-rest( :close );
say "4. Exit is { $proc.exitcode }";
}

The fourth situation reports a different exit code:

This goes to standard error
This goes to standard output
1. Exit is 137
This goes to standard error
2. Exit is 137
This goes to standard output
3. Exit is 137
4. Exit is 0

Re: [perl #130715] IO::Handle::close shouldn't decide what's a failure

[brian d foy]

If something segfaults, that's a different issue (that I haven't
submitted yet(. The exit code shouldn't have a value at that point, I
don't think. If the program didn't exit, the Proc object shouldn't
have an exit code for it.

But, notice in the example I provided in this report, I am checking
the exit code. I'm not debating that.

Re: [perl #130715] IO::Handle::close shouldn't decide what's a failure

[brian d foy]

I shouldn't have to catch an exception for something doing exactly
what I want it to do. I don't think it's the language designer's place
to add why I might run grep from Perl 6, but the easy answer is
testing (as I showed in the original message).

[perl #130715] IO::Handle::close shouldn't decide what's a failure

[brian d foy]

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


While trying to work around #125757 (using :out
makes the Proc object always return zero, I ran
into a different problem. I was writing test code
to check what a program does in cases where it
should exit with a non-zero status.

The docs for IO::Handle::close say only:

Will close a previously opened filehandle.

But other close methods mention using a LEAVE
phaser to avoid exceptions. I end up with kludgey
code like this to fight against Perl 6 thinking it
knows better than I do when something failed:

subtest {
my $proc = run $*EXECUTABLE, $program, '-k', :err;
my $message = try { $proc.err.slurp-rest };
LEAVE { quietly { $proc.err.close  } }

like $message, rx:i/invalid/, 'Invalid option warns';
is $proc.exitcode, 2, 'exit code';
}, "{$program} exits with false value with unknown switch";

Now, indeed this returned a non-zero exit status.
But, it did exactly what I wanted it to. This
isn't a failure in my code and it shouldn't be
exceptional.

Beyond that, there are many programs that use a
non-zero exit to mean something that isn't
failure. grep(1), for instance, uses 1 to mean no
lines matched. And so on. Perl 6 doesn't know
these, and I don't think it should make decisions
at this level.

I wouldn't mind the ability to throw an exception
if Proc was told to do that (say, like
:raise-exception similar to DBI's RaiseError).
But, it's easy enough for the programmer to make
this call on their own.

[perl #130653] The Proc from run() and :out seems always to report exitcode 0

[brian d foy]

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


It seems that the exit value that a Proc object returns isn't
always what I expect. In the calls where I specify :out, the
exit code seems to always be 0.

use Test;

my $program = '/usr/bin/false'; # maybe yours is different

ok $program.IO.e, 'program exists';

subtest {
my $proc = run $program;
is $proc.exitcode, 1, 'No arguments';
}, 'run with no arguments';

subtest {
my $proc = run $program, :out;
is $proc.exitcode, 1, 'Output specified, check exit before
read'; # is it finished running?
$proc.out.slurp-rest;
}, 'run with :out argument, read after';

subtest {
my $proc = run $program, :out;
$proc.out.slurp-rest;
is $proc.exitcode, 1, 'Output, check exit after read';
}, 'run with :out argument, read first';

subtest {
my $null = $*SPEC.devnull.IO.open;
# the program shouldn't compile and perl6 should return 1
my $proc = run $*EXECUTABLE, '-c', $program, :out, :err($null);
$proc.out.slurp-rest;
is $proc.exitcode, 1, 'Output, check exit after read';
}, 'compile check, read first';

done-testing();

And, the output:

ok 1 - program exists
ok 1 - No arguments
1..1
ok 2 - run with no arguments
not ok 1 - Output specified, check exit before read
1..1
not ok 3 - run with :out argument, read after
not ok 1 - Output, check exit after read
1..1
not ok 4 - run with :out argument, read first
not ok 1 - Output, check exit after read
1..1
not ok 5 - run with :out argument, read first
1..5

# Failed test 'Output specified, check exit before read'
# at /Users/brian/Desktop/false.p6 line 18
# expected: '1'
#  got: '0'
# Looks like you failed 1 test of 1

# Failed test 'run with :out argument, read after'
# at /Users/brian/Desktop/false.p6 line 16

# Failed test 'Output, check exit after read'
# at /Users/brian/Desktop/false.p6 line 25
# expected: '1'
#  got: '0'
# Looks like you failed 1 test of 1

# Failed test 'run with :out argument, read first'
# at /Users/brian/Desktop/false.p6 line 22

# Failed test 'Output, check exit after read'
# at /Users/brian/Desktop/false.p6 line 33
# expected: '1'
#  got: '0'
# Looks like you failed 1 test of 1

# Failed test 'run with :out argument, read first'
# at /Users/brian/Desktop/false.p6 line 28
# Looks like you failed 3 tests of 5

The details:

$ perl6 -v && uname -a
This is Rakudo version 2016.11 built on MoarVM version 2016.11
implementing Perl 6.c.
Darwin macpro.local 14.5.0 Darwin Kernel Version 14.5.0

[perl #130637] Odd segfaults with a small grammar

[brian d foy]

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


This program consistently segfaults for me:

grammar Grammar::Foo {
rule TOP {
'z' | 
}
token unicode_escape { '\\u' :i <[0..9a..f]> ** 4 }
}

my $res = Grammar::Foo.parse( '\u2603' );


This one blows up and writes a bunch of long hex numbers to the terminal:

grammar Grammar::Foo {
rule TOP {
'z' | 
}
token unicode_escape { 'u' :i <[0..9a..f]> ** 4 }
}

my $res = Grammar::Foo.parse( 'u2603' );

I stripped this down from a much larger thing I was working on, and
if I remove anything else I don't have the problem.


And, some details:

$ perl6 -v
This is Rakudo version 2016.11 built on MoarVM version 2016.11
implementing Perl 6.c.
$ uname -a
Darwin macpro.local 14.5.0 Darwin Kernel Version 14.5.0

[perl #130634] Should Perl 6 be able to untangle the inclusion of the same role from different sources?

[brian d foy]

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


I posted this to Stackoverflow without anyone pointing out the error
of my ways, so I think this is probably a bug.

http://stackoverflow.com/q/41791602/2766176

Imagine a series of complex grammars represented as roles, although
this simple example is enough to show the conflict:

role Alpha {
token alpha { :i <[A..Z]> }
}

role Digit {
token digit { <[0..9]> }
}

role Either
does Alpha
does Digit {
token either {  |  }
}

grammar Thingy
does Either
does Alpha
{
token TOP {  * }
}

my $match = Thingy.parse( '1a3' );
dd $match;

This doesn't work because Perl 6 doesn't untangle the relationships to
figure out that the conflict is actually the same thing from the same
source:

Method 'alpha' must be resolved by class Thingy because it exists
in multiple roles

But, reading [S14](https://design.perl6.org/S14.html), I see:

A role may not inherit from a class, but may be composed of other
roles. However, this "crony" composition is not evaluated until
class composition time. This means that if two roles bring in the
same crony, there's no conflict--it's just as if the class pulled
in the crony role itself and the respective roles didn't. A role
may never conflict with itself regardless of its method of
incorporation.

I read that to mean that the roles are applied as late as possible, so
the class `Thingy` would be able to disentangle that `Alpha` is
included in two different parts. I figured this would work something
like creating a list of all of the roles that would make up the final
class, then applying that list only to the final class. That way,
something like `Either` would mix-in only the things it defined and
would rely on the later composition to bring in `Alpha`.

I ran across this when I was trying to implement grammars for various
(IETF) RFCs. Many of them reference the grammars from other RFCs,
which makes it impossible for Perl 6 to resolve inheritance by C3. So,
I figured that roles would disconnect the relationships. Apparently it
doesn't.

[perl #130549] <:Digit> apparently matches anything

[brian d foy]

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


I mistakenly tried to match the Unicode property <:Digit> when I meant
number. It's not one of the properties listed in the table in Regexes[1],
although it is in perluniprops[2] as a Perl 5 extension as a synonym
for XPosixDigit. I didn't mean to use it and I don't particularly care if
Perl 6 supports it. However, I didn't get an error and it appears to
match everything (almost):

$ perl6 -v
This is Rakudo version 2016.11 built on MoarVM version 2016.11
implementing Perl 6.c.
$ perl6
To exit type 'exit' or '^D'
> q/'/ ~~ rx/ <:Digit> /
｢'｣
> q/a/ ~~ rx/ <:Digit> /
｢a｣
> qq/\c[CAT FACE]/ ~~ rx/ <:Digit> /
｢｣
> q/'/ ~~ rx/ <:SomeStupidThingIMadeUp> /
(Any)

The <:SomeStupidThingIMadeUp> non-existent property fails to match,
which is fine. Regex[1] says:

...<:property> , where property can be a short or long Unicode
General Category name.

"can" is a bit ambiguous since it might mean it "is limited to" or is
"not disallowed". It should probably be the more limited form ("it
must be a") and fail otherwise.

There are about 2,625 characters that don't match in this range:

my $matches = 0;
for 0 .. 0x10fffd {
unless chr($_) ~~ / <:Digit> / {
put $_.fmt('%#6X'), ": ", chr($_);
next;
}
$matches++ if chr($_) ~~ / <:Digit> /;
}

put "Characters not matching: ", 0x10fffd - $matches;


[1] https://docs.perl6.org/language/regexes#Unicode_properties
[2] http://perldoc.perl.org/perluniprops.html

[perl #130490] spurt throws on encoding issue, instead of returning Failure

[brian d foy]

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


On encoding failure, spurt throws an exception immediately instead
of returning a Failure (https://docs.perl6.org/routine/spurt):

my $path = $*SPEC.catfile( $*SPEC.tmpdir, $file );

unless my $rc = spurt $path, 'İstanbul', enc => 'iso-8859-1' {
my $e = $rc.exception;
put "unless: {$e.^name}: {$e.message}";
}

CATCH {
put "Caught {.^name}: {.message}";
}

I get the CATCH block instead of the unless:

Caught X::AdHoc: Error encoding Latin-1 string: could not encode
codepoint 304
Error encoding Latin-1 string: could not encode codepoint 304

[perl #130489] spurt throws exception instead of returning failure on encoding issue

[brian d foy]

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


On encoding failure, spurt throws an exception immediately instead
of returning a Failure (https://docs.perl6.org/routine/spurt):

my $path = $*SPEC.catfile( $*SPEC.tmpdir, $file );

unless my $rc = spurt $path, 'İstanbul', enc => 'iso-8859-1' {
my $e = $rc.exception;
put "unless: {$e.^name}: {$e.message}";
}

CATCH {
put "Caught {.^name}: {.message}";
}

I get the CATCH block instead of the unless:

Caught X::AdHoc: Error encoding Latin-1 string: could not encode
codepoint 304
Error encoding Latin-1 string: could not encode codepoint 304

[perl #130488] Trying to output something unrepresentable in the encoding throws X::AdHoc

[brian d foy]

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


Trying to output a character unrepresentable in the specified
encoding throws an X::AdHoc error. I think that should be X::IO,
and maybe there's enough issues here that an X::IO::Exception may
be interesting enough.

my $file = 'encoding_test.txt';
my $path = $*SPEC.catfile( $*SPEC.tmpdir, $file );

spurt $path, 'İstanbul', enc => 'iso-8859-1';

CATCH {
put "Caught {.^name}: {.message}";
}

Here'e the error:

Caught X::AdHoc: Error encoding Latin-1 string: could not encode
codepoint 304
Error encoding Latin-1 string: could not encode codepoint 304

Re: [perl #130419] |, ^, and & character class set operators aren't parseable

[brian d foy]

If it's going to be rejected, a note about why Perl 6 will not have
full, basic Unicode support (Level 1) would be nice.

Re: [perl #130460] Can we relax indir's test on the target directory?

[brian d foy]

I would expect indir to call chdir and let the exceptions fall where
they may. If I indir into something I'm not allowed to do, let the
exception come later. Even if I can execute that directory, it doesn't
mean I can read the files in it, for instance.

To me, the spirit of Perl has been "if that's what you want to do,
here you go". I'd rather take on the burden of handling things if they
blow up for things like this if it's a choice between that and not
even getting to try it.

Re: [perl #130419] |, ^, and & character class set operators aren't parseable

[brian d foy]

If these are intended to be future features (and for Unicode
compliance I think they are), maybe mark it as stalled instead. I tend
to think of rejected tickets as not valid or wrong, which this one
isn't. It's still something that needs to happen in the future.

[perl #130486] Should an unknown encoding throw X::IO instead of X::AdHoc?

[brian d foy]

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


I was playing with encodings for spurt. I wanted to output some
Turkish text, failed, and got an X::AdHoc exception. Should that be
X::IO, or maybe something else?

my $file = 'encoding_test.txt';
my $path = $*SPEC.catfile( $*SPEC.tmpdir, $file );

put "path is $path";

put "İstanbul is not Constantinople" if 'İstanbul' ne 'Constantinople';

#spurt $path, 'İstanbul', enc => 'latin9';
#spurt $path, 'İstanbul', enc => 'latin-9';
spurt $path, 'İstanbul', enc => 'iso-8859-9';

CATCH {
put "Caught {.^name}: {.message}";
}

I get:

Caught X::AdHoc: Unknown string encoding: 'iso-8859-9'

I figured that the encoding wouldn't be found because it's not listed
in /src/core/Rakudo/Internals.pm in the $encodings associative even
though it looks like there is a passthrough as the last resort. I did
not suss out who actually throws this exception.

[perl #130464] Should the way to set tmpdir from the environment be known to the user?

[brian d foy]

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


I was looking at how tmpdir does its work so I can explain what people
need to do in order for it to do its work. All of the current IO::Spec modules
currently inherit from IO::Spec::Unix, and it looks like these three have
the same tmpdir code that differs only by the list of directories to try:

IO::Spec::Unix
%*ENV,
'/tmp',

IO::Spec::Win32 (is IO::Spec::Unix)
$ENV,
$ENV,
$ENV,
'SYS:/temp',
'C:\system\temp',
'C:/temp',
'/tmp',
'/',

IO::Spec::Cygwin (is IO::Spec::Unix)
%ENV,
"/tmp",
%ENV,
%ENV,
'C:/temp',

I have a couple of questions about that.

0. I mostly want to be able to say "Set FOO to set the temporary
directory" and have that be a solid commitment from Perl 6. The docs
for $*TMPDIR and tmpdir do not document how they decide what value to
have.

1. Aside for platform specific expectations, should tmpdir look at
environment variables in the same order? Notice that in Cygwin, '/tmp'
shows up in the middle (right after TMPDIR, like in Unix), but it
would also look in other environment variables. I tend to think that
if an environment variable is set, it should come before a hard-coded
solution. Notice also that Win32 and Cygwin check TMP and TEMP in
different orders. I saw on MSDN (from Raymond Chen, no less) that
Windows's GetTempFileName looks at TMP first and then TEMP, but I
don't think that matters much and most systems seem to set both to the
same value.
(https://blogs.msdn.microsoft.com/oldnewthing/20150417-00/?p=44213)

2. As a matter of code duplication, is there some issue or future work
that precludes having the derived classes define a directory order
while leaving tmpdir in the base class (IO::Spec::Unix)? The thing
that I would think might kill that is platform-specific filesystem
checks (ACLs? whatever NTFS does? etc) that are not be handled by the
unixy file test methods.

method temp-dirs-to-try { ... } # in each base class

method tmpdir { # only in the base class
my $ENV := %*ENV;
my $io;
first( {
if .defined {
$io = .IO;
$io.d && $io.r && $io.w && $io.x;
}
},
  self.temp-dirs-to-try
) ?? $io !! IO::Path.new(".");
}

3. Whatever those answers are, do we guarantee to a Perl 6 user a
particular way to set the value. For instance, someone writes a
portable program and tells their users to set TMP because that is what
works for them and they don't know about other options. But, someone
runs it on a Unixy place and they use TMP because the instructions say
to use that. I suppose this comes down to how much of the underlying
system and practice do you let leak through and your tolerance for "On
Unix set FOO, on Windows set BAR". That answer might be to tell
everyone that TMPDIR will always be checked first. But, also possibly
let users set all the same variables in each environment.

4. Or, it just doesn't matter because you should care where the
temporary files are.

5. Except, if none of the locations work, the temp files end up in the
current working directory (and is it odd to get that by
IO::Path.new(".") instead of $*CWD?), which might not have the
attributes required of the other candidates (that is, is writeable)?
That blows up potentially far away from the place that set it.

[perl #130460] Can we relax indir's test on the target directory?

[brian d foy]

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


indir is in S16 but not documented elsewhere, but it's a really cool
feature that I think many people will find useful. It's certainly much
more convenient

indir '/Users/brian', {
put "Directory is $*CWD";
}

indir '/etc', {
put "Directory is $*CWD";
}

The second one fails with

Failed to change the working directory to '/etc': did not pass 'd r w' test

I don't know why it insists that the directory be writable, expecially
when chdir itself is not as strict. I often change to a directory where
I want to merely read files, so I'd like to see the test relaxed.

And, since its undocumented, nobody else knows that it does this currently. :)

[perl #130456] $*HOME blows up if HOME isn't set

[brian d foy]

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


If the HOME environment variable is not set (say, as in
non-interactive sessions), using $*HOME throws an exception:

$ unset HOME
$ echo $HOME

$ perl6 -e 'put "HOME is $*HOME"'
Use of uninitialized value of type Any in string context.
Methods .^name, .perl, .gist, or .say can be used to stringify it
to something meaningful.
  in block  at -e line 1
HOME is

Curiously, $*TMPDIR is /tmp if the TMPDIR environment variable is not
set.

Maybe that's good and maybe not. But, trying to use homedir blows up the
same way tmpdir does (https://rt.perl.org/Ticket/Display.html?id=130455):

$ perl6 -e 'homedir( "/Users/brian" ); put "HOME is $*HOME"'
No such method 'chdir' for invocant of type 'Any'
  in block  at -e line 1

But, homedir isn't documented outside of S16 even though it appears to
be there somewhere. Trying to set $*HOME directly doesn't work either,
which is certainly perplexing:

$ perl6 -e '$*HOME = "/Users/brian"; put "HOME is $*HOME"'
Cannot modify an immutable Any
  in block  at -e line 1

I can set a key is a completely different variable to get it to work:

$ perl6 -e '%*ENV = "/Users/brian"; put "HOME is $*HOME"'
HOME is /Users/brian

And I can even set it to a directory that does not exist:

$ perl6 -e '%*ENV = "/Users/brian/not-there"; put "HOME is $*HOME"'
HOME is /Users/brian/not-there

The $*HOME variable is listed in . If it isn't set, it's documented to
be Nil, but it is apparently Any. That also appears to mess with the REPL:

$ perl6
I ran into a problem while trying to set up Linenoise: Cannot
resolve caller new(IO::Path: Any); none of these signatures match:
(IO::Path $: Cool $path, :$SPEC = { ... }, :$CWD = { ... }, *%_)
(IO::Path $: :$basename!, :$dirname = "", :$volume = "",
:$SPEC = { ... }, :$CWD = { ... }, *%_)
(IO::Path $: *%_)
Continuing without tab completions or line editor
You may want to consider using rlwrap for simple line editor functionality

To exit type 'exit' or '^D'
> $*HOME
(Any)
>

[perl #130455] Should I be able to change the temporary directory?

[brian d foy]

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


tmpdir doesn't appear to change directories. This is probably why I
had the problem with https://rt.perl.org/Ticket/Display.html?id=130454
(although I should have had a different error there).

It's not documented to do that in the various IO::Spec modules, but I was
trying stuff in S16 to see what works. Should I be able to change the temporary
directory as S16 says, or is it forever fixed and should be documented as
read-only?

my $dir = '/Users/brian';
my $dir-io = $dir.IO;

put "$dir is a dir:  " ~ $dir-io.d;
put "$dir is readable:   " ~ $dir-io.r;
put "$dir is executable: " ~ $dir-io.x;
put "$dir is writeable:  " ~ $dir-io.w;

tmpdir( $dir )

It looks like everything should work, but it doesn't:

/Users/brian is a dir:  True
/Users/brian is readable:   True
/Users/brian is executable: True
/Users/brian is writeable:  True
Cannot modify an immutable IO::Path
  in block  at /Volumes/Big Scratch/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/file_trials.p6 line 11

Or, assigning to it directly:

my $dir = '/Users/brian';
my $dir-io = $dir.IO;

put "$dir is a dir:  " ~ $dir-io.d;
put "$dir is readable:   " ~ $dir-io.r;
put "$dir is executable: " ~ $dir-io.x;
put "$dir is writeable:  " ~ $dir-io.w;

$*TMPDIR = $dir;

It says I can't assign to $*TMPDIR. How is it that I can't assign to
dynamic variable? What's the point of it being dynamic if it can't change?

Cannot modify an immutable IO::Path
  in block  at /Volumes/Big Scratch/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/file_trials.p6 line 11

Try it with my:

my $dir = '/Users/brian';
my $dir-io = $dir.IO;

put "$dir is a dir:  " ~ $dir-io.d;
put "$dir is readable:   " ~ $dir-io.r;
put "$dir is executable: " ~ $dir-io.x;
put "$dir is writeable:  " ~ $dir-io.w;

my $*TMPDIR;

tmpdir( $dir )

Now it's a different sort of error. This kinda makes sense because there's
nothing in $*TMPDIR and tmpdir expects IO::Spec. But why is the error in
chdir and not something that catches that the argument wasn't IO::Spec?

/Users/brian is a dir:  True
/Users/brian is readable:   True
/Users/brian is executable: True
/Users/brian is writeable:  True
No such method 'chdir' for invocant of type 'Any'
  in block  at /Volumes/Big Scratch/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/file_trials.p6 line 13

Use temp instead, and it's a different error (despite that temp was
used for this purpose in S16):

my $dir = '/Users/brian';
my $dir-io = $dir.IO;

put "$dir is a dir:  " ~ $dir-io.d;
put "$dir is readable:   " ~ $dir-io.r;
put "$dir is executable: " ~ $dir-io.x;
put "$dir is writeable:  " ~ $dir-io.w;

temp $*TMPDIR;

tmpdir( $dir )

Now it's a different sort of error:

/Users/brian is a dir:  True
/Users/brian is readable:   True
/Users/brian is executable: True
/Users/brian is writeable:  True
Can only use 'temp' on a container
  in block  at /Volumes/Big Scratch/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/file_trials.p6 line 11

[perl #130454] tmpdir tries to change the current working directory

[brian d foy]

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


Setting the temporary directory apparently tries to change the current
working directory, which I didn't expect. But, the documentation for
tmpdir doesn't say what it does (https://docs.perl6.org/routine/tmpdir).

put "Tempdir is " ~ $*TMPDIR;

{
my $dir = '/Users/brian/.tmp';
unless my $rc = tmpdir( '/Users/brian/.not_there' ) {
my $e = $rc.exception;
put "unless: Error changing to $dir " ~ $e.^name ~ ': ' ~ $e.message;
}
CATCH {
put "CATCH: Error changing to $dir " ~ .^name;
}
}

I expected that tmpdir would return a Failure, and maybe it does if it
doesn't change the current working directory. This may be related to
https://rt.perl.org/Ticket/Display.html?id=130418
("chdir appears to throw exception immediately").

I would only expect things that want to create a temporary file to use
the value of TMPDIR (say, like
https://github.com/perlpilot/p6-File-Temp). I don't need to know where
that is and wouldn't want the current working directory to be there.
I'd rather have the current working directory be the one where my
input files are.

[perl #130419] |, ^, and & character class set operators aren't parseable

[brian d foy]

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


The |, ^, and & character class (and Unicode property) set operators
aren't parseable:

> / <[abc] | [def]> /
===SORRY!=== Error while compiling:
Unable to parse expression in metachar:sym; couldn't find final '>'
--> / <[abc]⏏ | [def]> /
> / <[abc] ^ [def]> /
===SORRY!=== Error while compiling:
Unable to parse expression in metachar:sym; couldn't find final '>'
--> / <[abc]⏏ ^ [def]> /
> / <[abc] & [def]> /
===SORRY!=== Error while compiling:
Unable to parse expression in metachar:sym; couldn't find final '>'
--> / <[abc]⏏ & [def]> /
> / <[abc] + [def]> /
/ <[abc] + [def]> /
> / <[abc] - [def]> /
/ <[abc] - [def]> /

These are documented in https://docs.perl6.org/language/regexes but are
not marked as "not implemented" or something similar.

[perl #130418] chdir appears to throw exception immediately

[brian d foy]

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


Using chdir with a non-existent directory appear to throw the exception
immediately rather than using fail. The docs say
(https://docs.perl6.org/type/IO$COLON$COLONPath#routine_chdir):

If the directory change is successful then the IO::Path representing
the target directory is returned, otherwise it will fail with X::IO::Chdir.

Here's what I was doing. I expected to get a Failure object back from
chdir, which would be "handled" by being evaluated in Boolean context.
It would return False and run the unless block:

put 'Current working directory is ' ~ $*CWD;

my $file = '/not-there.txt';
put "$file is there: " ~ $file.IO.e;

unless my $r = chdir $file {
my $e = $r.exception;
put "UNLESS: chdir failed: " ~ $e.^name ~ "\n" ~ $e.message;
exit;
}
CATCH {
put "CATCH: chdir failed: " ~ .^name ~ "\n" ~ .message;
exit;
}

say "Cwd is now " ~ $*CWD;

Instead, CATCH handles the immediately thrown exception:

Current working directory is /Users/brian/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch
CATCH: chdir failed: X::IO::Chdir
Failed to change the working directory to '/not-there.txt': does not exist
Failed to change the working directory to '/not-there.txt': does not exist
  in block  at /Users/brian/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/files.p6 line 8

Actually thrown at:
  in any  at gen/moar/m-Metamodel.nqp line 3096
  in block  at /Users/brian/Dropbox/~~Writing/Perl
Writing/LearningPerl6/learning_perl_6/scratch/files.p6 line 8

[perl #130216] Does Perl 6 support POSIX character classes?

[brian d foy]

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


On https://docs.perl6.org/language/regexes , it says "POSIX character
classes", then lists the names of the POSIX character classes. When I
try these, they don't seem to respect the locale (see
http://stackoverflow.com/q/40863736/2766176).

If they don't respect the locale, then we shouldn't call them "POSIX"
since people will expect them to at as POSIX documents them.

-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

[perl #130185] Fwd: Should Perl 6 run MAIN if the file is required?

[brian d foy]

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


Here's a short Perl 6 program that declare a `MAIN` subroutine. I
should only see output if I execute the program directly:

$ cat main.pm6
sub MAIN { say "Called as a program!" }

And I see output when I execute the program directly:

$ perl6 main.pm6
Called as a program!

If I load it as a module, I see no output:

$ perl6 -I. -Mmain -e "say 'Hey'"
Hey

Same if I `use` it from inside the program, I see no output:

$ perl6 -I. -e 'use main'

But, if I use `require`, I get output:

$ perl6 -I. -e 'require '
Called as a program!

[Synopsis 06](http://design.perl6.org/S06.html#Declaring_a_MAIN_subroutine)
literally says _the compilation unit was directly invoked rather than
by being required_. Is there something else going on because `require`
works at runtime (although S06 doesn't exclude that)?

I get the same behaviour with Rakudo Star 2016.07 and 2016.10.

I realize that the Synopses are dated. Absent anything else noting
divergence from the design docs or the lack of documentation of the
feature in the docs, I think most people are going to assume the
original intent.

MAIN is very lightly documented in Language/functions.pod6. The
verbiage "relevant phasers" should be expanded so a reader knows whats
relevant. I didn't find anything in the docs that said MAIN shouldn't
run in some circumstances and not others. The docs seem to say that it
will always run, but that's not true either.

Also asked on Stackoverflow: http://stackoverflow.com/q/40778852/2766176

[perl #130184] [BUG] All digit words in angle-bracket word quoting don't come out the same as the literally quoted word

[brian d foy]

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


Adapted from the Stackoverflow answer at:
http://stackoverflow.com/a/40824226/2766176

I'm using moar (2016.10) on macosx (10.10.5) darwin (14.5.0) (These
variables are quite nice!)

This came out of a problem I had with set membership. It turns out
that the way you make the set matters, and the way you make the
candidate member matters. In my case, there's a bug with angle-bracket
word quoting.

I used the [angle-brackets form of the quote
words](https://docs.perl6.org/language/quoting#Word_quoting:_qw). The
quote words form is supposed to be equivalent to the quoting version
(that is, True under `eqv`). Here's the doc example:

 eqv ('a', 'b', 'c')

But, when I try this with a word that is all digits, this is not equivalent:

$ perl6
> < a b 137 > eqv ( 'a', 'b', '137' )
False

But, the other forms of word quoting are!

> qw/ a b 137 / eqv ( 'a', 'b', '137' )
True
> Q:w/ a b 137 / eqv ( 'a', 'b', '137' )
True

The angle-bracket word quoting uses
[IntStr](https://docs.perl6.org/type/IntStr):

> my @n = < a b 137 >
[a b 137]
> @n.perl
["a", "b", IntStr.new(137, "137")]

Without the word quoting, the digits word comes out as [Str]:

> ( 'a', 'b', '137' ).perl
("a", "b", "137")
> ( 'a', 'b', '137' )[*-1].perl
"137"
> ( 'a', 'b', '137' )[*-1].WHAT
(Str)
> my @n = ( 'a', 'b', '137' );
[a b 137]
> @n[*-1].WHAT
(Str)

[perl #129926] Make everything in Learning Perl 6

[brian d foy]

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


This is a special sort of ticket that can depend on other tickets.
That way things I track problems that show up in whatever I'm writing
about.

I'm not stopping to fix bugs, for the most part. I need to focus
writing the book. If things are broke, I'll jus note it an move on.
The most important thing is to figure out what something should do and
what the language's intent is. It's more important to teach people how
to think about the language than know its warts.

-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

[perl #129920] [BUG] Configure.PL does not protect whitespace in --prefix

[brian d foy]

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


In the rakudo-star-2016.07 release, the value given to Configure's
--prefix might end up with whitespace (even if the initial value does
not have it). This path is not quoted in nqp/Makefile, so that fails
and the build cannot continue.

I ran into this because I used a path that was a symlink:

% perl Configure.pl --gen-moar --prefix
/Users/brian/Dropbox/perl6s/rakudo-star-2016.07

Various things had the same problem:

% perl Configure.PL --gen-moar --prefix "/Volumes/Big
Scratch/Dropbox/perl6s/rakudo-star-2016.07"
% perl Configure.PL --gen-moar --prefix /Volumes/"Big
Scratch"/Dropbox/perl6s/rakudo-star-2016.07
% perl Configure.PL --gen-moar --prefix /Volumes/Big\\
Scratch/Dropbox/perl6s/rakudo-star-2016.07

Paths interpolated into shell programs or makefiles should be
protected in some fashion.

-- 
brian d foy <brian.d@gmail.com>
http://www.pair.com/~comdog/

Re: question about twigil ?

[brian d foy]

In article [EMAIL PROTECTED], herbert breunung
[EMAIL PROTECTED] wrote:

 currently just used for compile time constants like $?LINE allright so 
 far so good.
 but why not use that for all constants like
 
 my $?constant = 5;

The $? is telling us where the value came from, not that it's a
constant. Since it's a compile time value, it also happens to be
something that we can't change.

Re: Perl 6 fundraising and related topics.

[brian d foy]

In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:

 That's what made me come to the conclusion that it's really The Parrot
 Foundation.

It's not The Parrot Foundation. It's that NLNet gave a very large
targeted grant for Parrot. It's a single big donation that's driving
that. 

I'm working on a detailed history of all TPF grants, but I want to get
everything just right before I published it. You'll see that your
comment is not really true.

Re: Perl 6 fundraising and related topics.

[brian d foy]

In article
!!AAAYAJmSy7DjO29Fg/NooSGjnaXCgAAAEEc+mhI1TL9CiDgj
[EMAIL PROTECTED], Conrad Schneiker
[EMAIL PROTECTED] wrote:


 So over the next few months, I'm planning to learn about
 fundraising, and see what I can accomplish on behalf of Perl
 6 development. To that end, I'm soliciting:

It's not really a money problem. It's finding someone to give the money
to. I've been trying to force money on some people to work on Perl 6,
but they don't wants it, for whatever reason. Part of that is that TPF
officers aren't supposed to get grant money.

And, before you think about raising money, check how much money TPF
actually has. There is still half of the NLNet's $70k to be
distributed. for instance. It's not a fundraising problem. Find a
person who would take money before you spend too much time finding the
money. Targeted fundraising is more effective anyway :)

when(), smart matching, and

[brian d foy]

This is actually a bug from Perl 5, but Perl 5's given  is supposed to
act like Perl 6's given. The long post is in use.perl:

   http://use.perl.org/~brian_d_foy/journal/35682

I was playing with a when condition that used a logical operator to see
if the topic was both an element of an array and a key of a hash:

   given( $foo ) {
  when( @array  %hash ) { ... }
  }

I thought that should acting like two smart matches:

   given( $foo ) {
  when(  (@array ~~ $_)  (%hash ~~ $_) ) { ... }
  }

In Perl 5.10.0, it's acting like one smart match, which I'm pretty sure
is a bug:

   given( $foo ) {
  when(  ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
  }

Perl 5's perlsyn talks about smart matching with logical operators, but
I don't see that in S04 (or anywhere else). Knowing what is supposed to
happen in Perl 6 would help me fix the Perl 5.10 version. 

So what would Perl 6 do (WWP6D) ? :)

Re: when(), smart matching, and

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 :given( $foo ) {
 :   when(  ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
 :   }

 which is exactly what I would expect from Perl 5, unless when is
 really a very intelligent macro of some sort.  As far as I know
 Perl 5's when has no clue how to distribute a smartmatch.

Well, I don't think you'd expect that based on perlsyn, so it looks
like the docs need to change to match what it does. I think the idea in
P5 is seriously borken.

 To write what you want there, you'd need something like:
 
 when any(@array)  any(%hash.keys)  {...}

It's not that I want that, but I'm trying to figure out what happens
with the logical operators based on the P5 docs. I'm starting from the
syntax rules and finding out what I can do with them rather than
starting with a task and looking for a way to do it. My interest is how
I'm going to answer questions in front of a bunch of students who use
the rules in unexpected ways.

So, this isn't a Perl 6 issue, and I'll relay to the P5 folks that they
aren't even close, have no hope of being close, and that they'll have
to figure it out on their own. :)

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Smylers
[EMAIL PROTECTED] wrote:

 brian d foy writes:
 
  In article [EMAIL PROTECTED], Larry Wall
  [EMAIL PROTECTED] wrote:
  
   On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
   
   : In article [EMAIL PROTECTED], Larry Wall
   : [EMAIL PROTECTED] wrote:
   : 
   :  : Later in the Literals section of S02, there's a chart of the
   :  : corresponding forms for fat arrow, pair, and paren notation. It has
   :  : 
   :  :a = 'foo'  :afoo  :a(foo)

   You're confusing various levels here when you say same thing.
   They're the same in some ways and different in others.


 The colon can _also_ be used for forming adverbs (similarly to how the
 slash can be used for both regexes and division, in different places),
 but that doesn't effect the equivalence of the above.

The section where that table is talks about adverbs. This isn't just
the same characters being used for different things. Some pairs also
act like adverbs. See my earlier message on file test operators.

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
 : In article [EMAIL PROTECTED], Larry Wall
 : [EMAIL PROTECTED] wrote:
 : 
 :  : Later in the Literals section of S02, there's a chart of the
 :  : corresponding forms for fat arrow, pair, and paren notation. It has
 :  : 
 :  :a = 'foo'  :afoo  :a(foo)


 You're confusing various levels here when you say same thing.
 They're the same in some ways and different in others.

Well, I think the documentation is confusing it. If these notations are
not the same thing, should there be a table that shows the
correspondence of these forms? If the pair notation shouldn't be used
for adverbs, perhaps the documentation shouldn't note a generalized
adverbial form of Pair notation.

I guess I'll just leave it at that, though, and not bring it up again.

Re: perl 6 and web open source projects

[brian d foy]

[[ This message was both posted and mailed: see
   the To, Cc, and Newsgroups headers for details. ]]

In article [EMAIL PROTECTED], cdumont
[EMAIL PROTECTED] wrote:

 oh, it might not be relevant in many ways but :
 
 http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/
 
 http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml
 
 There's one thing I would like perl6 to shine in, is web and open source.

As Trey pointed out, this sort of discussion belongs somewhere else.
Note that no language really shines on the web: it's something that
someone makes with the language (e.g. Catalyst, Rails, Seaside, Django)
that shines on the web :)

Re: Pair notation for number radix

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 : Later in the Literals section of S02, there's a chart of the
 : corresponding forms for fat arrow, pair, and paren notation. It has
 : 
 :a = 'foo'  :afoo  :a(foo)
 : 
 : That looks like it might mean that these are corresponding forms:
 : 
 :8 = 377:8377:8(377)
 
 The first is just a pair of 8 and 377, and has no special numeric
 significance.  The adverbial syntax is special in that, for ordinary
 pairs, what follows the colon must be an identifier, so :8377
 would ordinarily be illegal. 

Did I miss this in the spec somewhere? I've basically assked the same
question in regards to file tests. I wouldn't be asking the question if
the spec didn't keep talking about pairs and adverbs being the same
thing. If the Pair and adverbs aren't different syntax for the same
thing, how should that affect that chart in S02?

 The :8(377) above is a bit wrong, by the way, and works only because
 decimal 377 happens to stringify to something that looks like an
 octal number.  You couldn't, for instance, say :16(deadbeef) unless
 deadbeef() was a 0-ary (or listop with no args) function returning
 a hex string.

Could you have :16('deadbeef')? Should the :8(377) still work (so, does
'wrong' mean it won't do what I'm thinking it will do, or that it does
mean that Perl 6 won't compile it, or some other sort of wrong)?

Re: Current roadmap for Perl 6 on Parrot

[brian d foy]

In article [EMAIL PROTECTED], Patrick R.
Michaud [EMAIL PROTECTED] wrote:


 
 How others can start hacking and contributing
 -
 
 If you're interested in hacking on the compiler, my suggestion 
 is to become somewhat familiar with the compiler tools already 
 available in Parrot. 

I'm not interested in hacking on the compiler, but I am interested in
writing tests. I've added some to the Pugs project, but that seems to
be a ghost town now. Is there a new plan for tests besides adding them
to the Pugs code? I'm not really into writing tests that won't ever
pass in Pugs. :)

Re: Some questions about using NaN and Inf

[brian d foy]

In article [EMAIL PROTECTED], TSa
[EMAIL PROTECTED] wrote:

 The only operator that can be used to investigate these values should
 be ~~ and the given/when statement that uses it. 

Why should that be true? What's wrong with treating it as an object
like anything else? 

The trick is limiting the number of special cases and exceptions to the
rule so beginners can form the right conceptual model of everything.

Re: Some questions about using NaN and Inf

[brian d foy]

In article [EMAIL PROTECTED], Moritz Lenz
[EMAIL PROTECTED] wrote:

 brian d foy wrote:
  * If I can match $x to NaN (or its stand-in), what happens when $x is
  undef? 
 
 undef is a property of the container variable (that it holds no value),
 whereas NaN is a property of the content (like 1/0). so undef ~~ NaN
 should be false IMHO.

That's fine, but the question people are going to ask is if undef
isn't a number, why doesn't iot match 'not a number'. If it doesn't
match, we have to talk about internals to explain it, which is
generlaly not a good idea for beginners :)

Re: Some questions about using NaN and Inf

[brian d foy]

In article [EMAIL PROTECTED], Darren Duncan
[EMAIL PROTECTED] wrote:

 At 3:20 PM -0500 10/6/07, brian d foy wrote:
 For comparisons, how are we going to use Inf and NaN? Are those going
 to be special flyweight objects, so:
 
 $x = 1 / 0;

 $x == Inf;# is it the same value
 $x === Inf;  # it is always the same object

 them.  By contrast, the =:= operator always tests if 2 things are the 
 same object or not, even for those of value types.

Maybe the belongs in Comparison types in S02 too :)

So, then, back to the question. People don't care how it's implemented
(and it would be great if we didn't have to explain it). What's the
idiom for the comparison going to be?

Some questions about using NaN and Inf

[brian d foy]

I'm thinking about how to explain Perl 6's numbers to the beginners
just picking up Learning Perl 6. I had some questions about NaN and Inf
(which I can't just try since neither Parrot or Pugs appear to know
about these yet).

* In S02's table of Immutable types,  it mentions that Int allows Inf
and NaN, but doesn't say anything about Num and Complex handling them. 
Is it that it's unexpected that Int would handle it, so you have to say
this explicitly, or um, I don't have a good alternative :)

   Int Perl integer (allows Inf/NaN, arbitrary precision, etc.)
   Num Perl number
   Complex Perl complex number

The complex and num  native type handles NaN accroding to Native
type, a couple of subsections back, and I'm confident that Num and
Complex should have them too. It just looked odd to me that only one of
Int, Complex, and Num said anything about it.

* will NaN, -Inf, or +Inf be literal values (or something close) so I
can use them in comparisons? e.g. $x ~~ NaN. I see uses of Inf in list
creation ( 1 .. Inf ), but can I use that everywhere?

* If I can match $x to NaN (or its stand-in), what happens when $x is
undef? There's a note about this in S02 (Conjecture: num might ...).
Native type say that an int type defaults to 0, which complicates
things for beginners, but if everything starts off as a num, it doesn't
matter until we talk about types.

* If I declare a sub to return a number of some sort (either by using
Cof or Cas, what happens when the value is NaN or Inf? I suppose
that should be fine as a return value, but it also seems that if
someone wants to impose some sort of constaint on the return value that
they wouldn't want exceptional values.

Re: Some questions about using NaN and Inf

[brian d foy]

In article [EMAIL PROTECTED], brian d foy
[EMAIL PROTECTED] wrote:

 I'm thinking about how to explain Perl 6's numbers to the beginners
 just picking up Learning Perl 6. I had some questions about NaN and Inf
 (which I can't just try since neither Parrot or Pugs appear to know
 about these yet).

Oi, sent that before I was done writing it. I was looking way back into
the past at Numeric literals, take 1

http://www.nntp.perl.org/group/perl.perl6.documentation/2002/11/msg205.h
tml

and wondering how much of that is should be in S02.

For comparisons, how are we going to use Inf and NaN? Are those going
to be special flyweight objects, so:

   $x = 1 / 0;
   
   $x == Inf;# is it the same value
   $x === Inf;  # it is always the same object

Pair notation for number radix

[brian d foy]

This is basically the same question I had about file test operators
earlier
(http://www.nntp.perl.org/group/perl.perl6.language/2007/04/msg27415.htm
l). I never got an answer on my syntax question and the discussion went
off to talk about file tests instead of pair notation. 

From S02 The general radix form of a number involves prefixing with
the radix in adverbial form.

This seems to say that there are non-general radix forms, and that
those might involve a different radix form that's not adverbial.

Later in the Literals section of S02, there's a chart of the
corresponding forms for fat arrow, pair, and paren notation. It has

   a = 'foo'  :afoo  :a(foo)

That looks like it might mean that these are corresponding forms:

   8 = 377:8377:8(377)

Now, if I can do that, what happens to the pair form in a hash composer
when I want the key of '8' and the value of :10377?

Also, going a bit further, the table lists

   a = foo bar  :afoo bar  :a(foo bar)

So can I do things like

   255 = 10 1 0 6;  # hey, that looks like an IP address

   :25510 1 0 6; # is that the same as :255[ 10,1,0,6 ] ?

And, if that works, what might this do? 

   q:w:25510 1 0 6

Re: Micro-articles on Perl 6 Operators

[brian d foy]

In article [EMAIL PROTECTED], Alberto Simões
[EMAIL PROTECTED] wrote:


 Adriano Ferreira wrote:
  The plan is to write a series of  blog entries discussing a Perl 6
  operator at a time or a small group of closely related ones.
 
 I think the idea is cool. Also, I do not know how periodically that 
 would be, but it might be a good idea to join some of them in turns and 
 ask brian d foy to publish them in TPR as well.

Yes, I'd publish them. :) However, I don't want to publish something
that's already on Perl.com.

[perl #43761] [PATCH]: Add lib/Perl/Critic to the no_index key in META.yml

[brian d foy]

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


Some of the Perl::Critic modules are still in the Parrot distro, but
they don't belong (in the PAUSE sense) to Parrot. This patch tells the
PAUSE indexer not to look at them.

If you can get this patch in before today's release, then the next
distro shouldn't be Unauthorized.

-- 
brian d foy [EMAIL PROTECTED]
http://www.pair.com/~comdog/
Index: META.yml
===
--- META.yml(revision 19611)
+++ META.yml(working copy)
@@ -12,6 +12,7 @@
 - lib/Digest
 - lib/File
 - lib/Parse
+- lib/Perl/Critic
 - lib/Pod
 - lib/Test
 - lib/Text

[perl #43567] [PATCH] Parrot::Configure::Data: Check for Sortkeys instead of Data::Dumper version

[brian d foy]

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


The PAUSE indexer is confused by Parrot::Configure::Data because it
sees a line that has $Data::Dumper::VERSION in it. ExtUtils::Makemaker
has the same problem, because PAUSE and Makemaker look for
/([\$*])(([\w\:\']*)\bVERSION)\b.*\=/ in the source.

In the two places I saw $Data::Dumper::VERSION, Parrot really just
wants to know if Data::Dumper has Sortkeys(). Just check directly with
can(). As far as I can tell, no new test failures happen from this
change on my machine.

Once you fixup this problem, I can make some more clean-ups for the
parrot distro in PAUSE and finish moving all the distro modules to the
PARROTRE user. :)

-- 
brian d foy [EMAIL PROTECTED]
http://www.pair.com/~comdog/


data-dumper-sortkeys-patch.patch
Description: Binary data

Re: Referring to source code within Perldoc: the new A code

[brian d foy]

In article [EMAIL PROTECTED], Smylers
[EMAIL PROTECTED] wrote:

 Juerd Waalboer writes:
 
  Smylers skribis 2007-06-21 21:33 (+0100):
  
   I disagree.  perldoc.perl.org was started by JJ, gained popularity,
   and then got awarded the official blessing of the onion.  Over the
   years there have many several sites with Perl documenation.
  
  That's not a way of documenting things, it's just an interface to
  existing documentation.
 
 There's no reason why it has to be.  There are no barriers to anybody
 unofficially adding extra semantic information to the documentation and
 making it available on a website.

The biggest barrier is that any work one does outside of the
documentation source is likely to be wasted when new versions of the
module comes out. Consider the Phalanx project for instance: they got a
lot of people working to improve a lot of modules, and almost none of
that work actually made it into the modules.

The next biggest barrier is the size of the job. Who's going to go
through all that documentation on CPAN and tag everything? I wouldn't
even want to do it on all of my modules.

There isn't a technical problem, but there is a huge social and
pragmatic problem. It would be very nice if the documentation had a
natural way to do this without extra-documentation clues from third
parties.

Some Things I'd Like To Do With Pod

[brian d foy]

I have a feeling we've sorta assumed some use cases for whatever Pod
design we're advocating, so I thought I'd write down what I'd like to
do with Pod. At this level, I don't care how it gets done, which model
it uses, or anything else.

This isn't a fantasy wishlist of anything I think I might want. These
are things that I've wanted for a couple years. I'm not trying to start
an RFC process, but think about how to motivate some of the things we
are debating. These are just use cases, not really feature requests:

==Pull out the docs for a single method.in a class

I want perldoc -f for modules. That works for perlfunc because there is
a simple structure to the file where all the =item represent a function
(and similarly for perldoc -q and the perlfaq).

I'm not thinking ahead to what the method docs would look like. If I
had this I'd be happy just to get plain text.

==Know which class the Pod is in

One of the failings of Pod::Coverage right now is that it assumes that
there is only one class per file and the filename represents the class.
This means I can't use Pod::Coverage or Test::Pod::Coverage when Ihave
a design that doesn't do that (e.g. a convenience class that's private
and only a screen long).

I'd really like a Pod parser to know what class it is in, and which
class the documentation belongs to.

===Per class documentation, not per file documentation

Related to the one above, I'd like to have NAME, SYNOPSIS, etc. for
each class, not just per file. Well, what I really want is the
Smalltalk class and method browsers, but I know I'm not going to get
those. It's a major missing feature from my perlbrowser tool (on CPAN).
Part of that means, though, that if I want that docs for Foo::Bar which
live in Foo.pm, then perldoc6 has to know how to find that class.
That's a much larger issue than just the Pod format.

If I put more than one class in a file, I'd like to be able to extract
it's documentation separately. Of course, this leads to huger problems
making it work, so I'm not holding my breath. It's more likely I'll
have to live with separate files :)

Private docs

There's documentation for module users, and there is documentation for
module developers. I'd like to document the private methods too, but
without something to tell perldoc6 that you want the secret docs, you
don't see them. The secret docs are for the people working inside the
code of the class (creators, maintainers, whatever), and those docs are
just like the user docs in structure.

Re: Referring to source code within Perldoc: the new A code

[brian d foy]

In article
[EMAIL PROTECTED], Damian
Conway [EMAIL PROTECTED] wrote:

 Mark Overmeer wrote:
 
 [...yet another honest and heartfelt plea for Pod 6 to be something
 entirely different from what it is currently designed to be.]
 
 The solution is simple, you know, Mark. Why not just write up your own
 alternate S26, redesigning Pod 6 the way you think it should work, and
 then publish your proposal for consideration here?

Couldn't most of this be figured out by making Pod6 extensible (or
whatever the right term is). Pod6 would be more of the syntax and basic
operation, but other people could have custom directives that their
Pod6 translators and formatters could then use. That is, not all of
this has to be in the spec if the spec has a way to make it possible
later. :)

And, as far as writing a new S26, does this mean that this really isn't
open to discussion? That is, if we want something different than you
want we have to have competing specs and there won't be any compromise?

Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn

[brian d foy]

In article
[EMAIL PROTECTED], Chaddaï
Fouché [EMAIL PROTECTED] wrote:

 The Learning Perl 6 argument seems
 equally contrived to me since anyway you don't need POD to understand
 programming in Perl and I never actually learned POD until I wanted to
 do a real module and document my little console utilities in Perl.

That's exactly my argument. You didn't need to learn that because you
weren't specifically doing anything with Pod. It doesn't even come up
because it's something you have to affirmatively do, and it's not
something that accidentally happens.

 And if some do it, hell, I seriously
 doubt that their program would be in the scope of the beginning of
 Learning Perl 6 !! You didn't put -+- there in previous versions,
 did you ?

I'm not sure what you mean mean by - + -.

Our current Learning Perl class starts off with a little Pod
manipulation because we know that everyone (should!) has the perldoc
along with their Perl. My actual experience trumps your serious doubt
:)


 The other problem is that if somehow a braindead guy (where would he
 get the idea from, I never saw such a style) put his = in first
 column expecting a assignment he won't get it... Seriously ? Are you
 really allowing for such weirdness in introductory material to a
 Language course ?

How is that braindead? It's perfectly fine, allowable, and intended
that a Perl 5 programmer can break statements over more than one line.
It's not weird at all.

I've taught a lot of beginner Perl classes, and people do all sorts of
things.


 So in my opinion, it would be fine to let slip that you can also
 create some kind of comment/doc by putting a = in the first column in
 the first chapter, and let the subject of POD for a later chapter.

The problem is that once you bring something up, people want to know
why you brought it up, and then they start playing with that point to
see what you meant. All of a sudden, you're explaining a lot of stuff
that doesn't get people any closer to completing a simple program.

As I've said previously, the rule for Pod looks simple, but the rules
for other things, such as strings, are now more complicated. However,
Larry mentioned that the Pod extractor may do what it likes, but Perl
shouldn't have to live with it's decisions about what is executable
code and what isn't, so it may still work out.

Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn

[brian d foy]

In article [EMAIL PROTECTED], Damian Conway
[EMAIL PROTECTED] wrote:

[writing publicly to head off any notions there's a personality problem
here]

 brian wrote:

   I know you think it's easier to teach and explain, but that's because
   you came up with it.
 
 I hope I'm not that shallow. 

I didn't mean to imply anything about your character there, but that
naturally as thinking beings we all understand much better than anyone
else our own thoughts and architectures.

It's not that your shallow, it's that you've visited the deepest
trenches in the murky oceans and now have to figure out how to explain
the wonderful creatures you saw to people who don't want to get wet.
You're going to understand it much more because you've actually seen
those creatures. :)



   There are other things to consider, and to me it looks like this
   design decision isn't based on what's easier for the Perl 6 programmer
   but what's easier for the implementors.
 
 I assure you that that is categorically *not* the case (as I'll discuss
 at length in a subsequent message).

I wasn't trying to assign any ethical baggage to that remark, and said
in an earlier message that it's a matter of philosophy about what
different people value most.

I still think it's a true statement though, and that the difference is
an honest disagreement about how the world should be.

Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn

[brian d foy]

In article [EMAIL PROTECTED], brian d foy
[EMAIL PROTECTED] wrote:

 There are other things to consider, and to me it looks like this design
 decision isn't based on what's easier for the Perl 6 programmer but
 what's easier for the implementors.

My comment here was offensive to Damian (and possibly others), and I
apologize for that. 

I should have explicitly noted my context for this thought: some poor
programmer sitting alone with no knowledge of how Perl 6 got to be how
it is (that is, the audience for Learning Perl 6). I didn't mean to
apply this to Damian or anyone else specifically, and that we all know
each other makes my comment reasonably seem like I'm pointing at
specific people for this remark.

From this, Damian and I had a minor misunderstanding, and after a
couple of private emails we've cleared it up and are still friends. :)

I apologize for the inconvenience,

Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn

[brian d foy]

In article [EMAIL PROTECTED], Damian Conway
[EMAIL PROTECTED] wrote:

[ First, I should note that whatever we end up with, that's the party
line and that's what I teach, but before we end up there, I know from
my years of experience teaching that certain sorts of questions are
going to come up. I'm looking at this from the perspective of the
student sitting in a class, not from the implementors perspective. ]


 brian wrote:
 
   As you know, one of the biggest complaints about Perl is that you have
   to have a lot of special rules knowledge to figure some things out.
   Whether that is true doesn't really matter: people still complain about
   it.
  
   In this case, it will actually be true.
 
 I don't think that's the case.

I'm speaking at the programmer level, not the implementor level. For the
guy in the trenches, this is a special case. This is more complexity
for the guy typing code, even if it's easier syntactically for the guy
writing the parser.


   This impacts Learning Perl 6 rather early because it's a rule that
   people need to know at the same time that we tell them that whitespace
   is insignificant.
 
 I'm pretty sure Learning Perl 6 won't say that.

Well, it won't say that if it's not true, but until pretty recently
it's been mostly true.

 The rule you have to teach under the Separation model is:
 
  Any line that starts with an = is Pod...and not part of your program.

And that's something that now comes up very early in teaching the
assignment operator. 


 Whereas the rule you have to teach under the Integration model is:

We don't teach any rule under this model, and it's been fine for over a
decade :)

When we do teach the current Pod, the simple rule is that Pod starts:

   * when Perl is expecting a new statement
   * there is a =something at the beginning of the line

Which is considerably simpler than the long rule list you used to say
the same thing (which seems a bit of FUD, honestly).


   So, if this is the case, how will a new Perl 6 user debug a program
   failure when part of their program mysteriously disappears because
   they just happened to have =begin at the beginning of a line?
 
 The same way they debug it when part of their program mysteriously
 disappears because they just happened to have # at the beginning of a
 line: 

 Except, of course, the Pod mysteriously vanishing will be considerably
 easier to debug, because ALL lines starting with =begin vanish, whereas
 only some lines beginning with # do.

That's not really the case. The # only affects one line, and a pound in
a literal string doesn't start a comment. People grok single line
comments very well. 

The start of a Pod comment now affects it's line and the ones following
it.


 
   Also, doesn't this then limit Pod to Perl 6 (which I thought was not
   the goal)? I doubt other languages will want to deal with this
   situation.
 
 As Smylers so ably pointed out, enabling Pod to be parsed independently
 of the underlying language syntax actually makes it vastly easier to use
 Pod with other languages.

Well, easy to use Pod with other languages until they try to use the
assignment operator at the beginning of the line, or a = in a literal
string at the beginning of a line.


I know you think it's easier to teach and explain, but that's because
you came up with it. The notion that a special character in a certain
column means something was tough to explain to other people in FORTRAN
too.


There are other things to consider, and to me it looks like this design
decision isn't based on what's easier for the Perl 6 programmer but
what's easier for the implementors. It's not that I don't understand
both sides, I just disagree about where the complexity should be.

Re: = at Start of Line ([svn:perl6-synopsis] r14421 - doc/trunk/design/syn)

[brian d foy]

In article [EMAIL PROTECTED], Smylers
[EMAIL PROTECTED] wrote:

 brian d foy writes:
 
  In article
  [EMAIL PROTECTED], Damian
  Conway [EMAIL PROTECTED] wrote:
  
   No. It's Pod. *Any* line that begins with '=begin' always starts a Pod
   block. Always.
  
  As you know, one of the biggest complaints about Perl is that you have
  to have a lot of special rules knowledge to figure some things out.
 
 Indeed.  What's much nicer is to be able to state that a given rule
 always applies.

Well, now explain literal strings :)  This isn't about one rule, it's
about an ecosystem.

The rules for Pod5 always applied too, so I don't see what we've gained
here as far as the simplicity of rules (but let's not go
round-and-round on that since we've both already explained our
positions).

 Like Damian has just done here.

This is a point where a lot of people will disagree, I suppose, and
it's a fundamental sort of disagreeement where neither side will really
be convinced otherwise. I don't think this is stubbornness either, but
reflects what people value most. That is, nobody is really wrong,
because we'd have to define some way to measure that, and we're really
disagreeing on the yard stick.

Putting aside this particular situation, the argument comes down to
where does the water balloon pooch out? We haven't lost any complexity,
it's just in different places. Maybe some places need less complexity
and some places could stand a little more.

Now, in this particular situation, Pod is much easier to extract, but
literal strings now have extra baggage to consider. That's not what
we're debating though. The real debate is whether you think moving the
complexity around like that is worth it. 

Personally, extracting Pod from Perl 5 hasn't been a problem for me
(and I do a lot of Pod work and write lots of custom Pod translators),
so I don't think this re-distribution is worth it. I don't have to
answer many questions about extracting Pod, and I don't see many normal
people (meaning, not us) asking for easier ways to do this. I don't see
a motivation, for the perspective of normal people, for this. When we
through around terms like natural language, normal people matter. :)

You and Damian have explained the other side very well. I understand
it, and it's very easy for me to understand and even deal with. We just
disagree on the consequences. 

I tend to think that people like us are here to do the hard work so
other people don't have to think about this sort of stuff, so I don't
mind putting the complexity in the the parser if it takes it out of the
common program elements such as strings.

Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn

[brian d foy]

In article
[EMAIL PROTECTED], Damian
Conway [EMAIL PROTECTED] wrote:

 No. It's Pod. *Any* line that begins with '=begin' always starts a Pod
 block. Always.

As you know, one of the biggest complaints about Perl is that you have
to have a lot of special rules knowledge to figure some things out.
Whether that is true doesn't really matter: people still complain about
it.

In this case, it will actually be true. That a Perl 6 compiler might
actually decide that in the middle of a statement it isn't a statement
anymore but is Pod will cause some grief, not only in the here doc
example you show, but in things such as:


   my $x
   =begin();

This impacts Learning Perl 6 rather early because it's a rule that
people need to know at the same time that we tell them that whitespace
is insignificant. That's not really true anymore because a newline
followed by an = followed by begin is this special case, **no matter
how it shows up in the program**. Now there's this extra footnote to
explain this situation, and at the level of basic syntax, we have to
explain a lot more.

I realize that the motivation for this was to be able to scan a file
and extract the pod without parsing the Perl, but when the consequences
affect very basic language things, like where you put your whitespace
and operators,  then you create more of a mess than you solve.

So, if this is the case, how will a new Perl 6 user debug a program
failure when part of their program mysteriously disappears because
they just happened to have =begin at the beginning of a line? And, is
the tradeoff in language complexity worth the extra trouble?

Also, doesn't this then limit Pod to Perl 6 (which I thought was not
the goal)? I doubt other languages will want to deal with this
situation.

Default filehandles, or topicalizing filehandles, or something

[brian d foy]

I was thinking about default filehandles yesterday. select() doesn't
seem to be around except as an Unfiled function in S16. 

Then, as I was looking at 

   .say( Hello World );

and 

   $ERR.say( Hello standard error );

I figured this might work, and does. Topicalizing a filehandle kinda
acts almost like a default filehandle:

   $_ = $*ERR;
   .say( Hello standard error );

But, of course, that won't work for say() used as a function:

   say Hello standard error ;

Then, I thought I might assign to $*OUT, which doesn't work in pugs
(and I might have missed the part of the spec that says these are
read-only):

   my $saved_standard = $*OUT;
   $*OUT = $*ERR;   # this is an error

   say This goes to stderr;   # not until previous line works   
   say $saved_standard: This goes to stdout;  # just fine

Is there going to be a Perl 6 feature for this?

Current file name used by $*ARGS filehandle

[brian d foy]

Is there going to be a Perl 6 equivalent to $ARGV (the current filename
for the ARGV filehandle)?

This is something I wanted to use in an example in the Learning Perl 6
filehandles chapter:

http://www.learningperl6.com/Chapters/11.filehandles.html

Re: Current file name used by $*ARGS filehandle

[brian d foy]

In article [EMAIL PROTECTED], Larry Wall
[EMAIL PROTECTED] wrote:

 On Tue, May 01, 2007 at 10:04:50AM -0500, brian d foy wrote:
 : Is there going to be a Perl 6 equivalent to $ARGV (the current filename
 : for the ARGV filehandle)?
 
 Hmm, well, we did away with unsigiled filehandles, and renamed @ARGV
 to @*ARGS, so $*ARGS is presumably the magical filehandle, which means
 it can't really serve as the filename at the same time.  So assuming
 that any filehandle knows the name of its file (if available), it'd
 probably be available via a method like $ARGS.name or some such.

$ARGS.name seems reasonable enough, and the method could be very handle
for other things that use filehandles too. However, until it shows up
in a synopsis, I'll assume you're just thinking aloud rather than
making a decision. :)

What should file test operators return?

[brian d foy]

At the moment the file test operators that I expect to return true or
false do, but the true is the filename. I expected a boolean, for no
other reason than Perl 6 has them so it might as well use them. The
section on Smart Matching in S03 says that the ~~ doesn't have to
return a boolean,  but aside from things liek :s, :M, and :A, what good
would it be not to? I'm happy to update S16 with whatever the answer
is. :)


Here's my code example that motivates this question. For a Llama6
exercise with file test operators, I wanted to create a little table:

   for @files - $file {
  printf %-70s  %s  %s  %s\n,
 $file,
 $file ~~ :r,
 $file ~~ :w,
 $file ~~ :x;  
  }

I get the filename for each part:

   foo   foo  foo  

Which I wanted to work like this perl5 (not that I care if it's
different, I just have to explain it to reader)

   #!/usr/bin/perl5
   foreach ( glob( * ) )
  {
  printf %30s %s %s %s\n, $_, -r, -w, -x
  }


With the Pugs 6.2.13 (r15868), only the ~~ form seems to work, but is
that going to be any different than the other two forms?




pugs ( Talks ~~ :r ).say
Talks
Bool::True
pugs ( Talks ~~ :d ).say
Talks
Bool::True

pugs Talks.TEST(:s).say
*** No such method in class Str: TEST
at interactive line 1, column 1-21

pugs Talks.:s
Internal error while running expression:
*** 
Unexpected :s
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9
pugs Talks.:d
Internal error while running expression:
*** 
Unexpected \:
expecting ., \187, , =, operator name, qualified
identifier, variable name, ..., --, ++, i, array subscript,
hash subscript or code subscriptat interactive line 1, column 9