[perl #132191] [REGRESSION] Possible rakudo regression (issues with IRC::Client)

[via RT]

# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #132191]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132191 >


There is very little known about the problem. I'm creating this ticket so that 
there's something we can link to when needed.

IRC::Client ticket: https://github.com/zoffixznet/perl6-IRC-Client/issues/51

Bisected to 
https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2

Bisect log: 
https://gist.github.com/Whateverable/56e1148a3c09995baf0ba7f6c4749f67

There's a chance that this is a serious regression that should be fixed in 
rakudo. Or it could be that there's something wrong in IRC::Client. Any 
additional information is appreciated.

Re: Tip: assign a value to a hash using a variable as a key

[Brandon Allbery]

On Sat, Sep 30, 2017 at 10:30 PM, ToddAndMargo 
wrote:

> On 09/30/2017 02:15 PM, Brandon Allbery wrote:
>
>> Basically: < > is single quotes and treats variables and expressions as
>> literals. << >> is double quotes and interpolates variables but not general
>> expressions. And { } does no quoting at all and uses general expressions.
>
>
This gets a little complex...


> 1) expressions
>
> 2) the difference between "expressions" and "general expressions"
>

Doublequoted strings don't just expand variables. Postfixes (like [] or <>
to look up values in arrays/hashes) are also understood; method calls on
variables also work, as long as they end with a parenthesized expression
(so, "hi $foo.name" will not work (it'll expand '$foo' instead of '$foo.name')
but "hi $foo.name()" will, provided $foo contains an object with a 'name'
method). This is what I meant by 'expression', which I should have probably
called 'simple expression' or something.


> 3) Quoting.  The difference between "" and <>
>

' ' strings and <> postfixes are almost identical. %foo is the same as
%foo{'a'}. But %foo acts like you did: %foo{'a'}, %foo{'b'}
" " strings and << >> postfixes are almost identical. %foo<> is the same
as %foo{"a"}. But %foo<> acts like you did: %foo{"a"}, %foo{"b"}

Inside ' ' strings, everything is literal.
Inside " " strings, variables like $foo and (simple) expressions (described
above) will be replaced by their values; and you can use { } to insert the
result of any expression. (This also works in << >>.)

pyanfar Z$ 6 'my %x = ("a"=>"b","c"=>"d", "e"=>"f"); my $v = "b"; say
%x<>'
(b d)

4) "interpolating" as it refers to Perl (not math, where you "guess"
> what a value is based on values on both sides of you).
>

Replacing something inside a string with the string representation of its
value. This sense is also used in documentation for the shell, where you
can also interpolate `` subcommand output and such.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Tip: assign a value to a hash using a variable as a key

[ToddAndMargo]

On 09/30/2017 02:15 PM, Brandon Allbery wrote:
Basically: < > is single quotes and treats variables and expressions as 
literals. << >> is double quotes and interpolates variables but not 
general expressions. And { } does no quoting at all and uses general 
expressions.


Hi Brandon,

I am writing up what you just said for my keepers file.

Would you please define for me what you mean by the following:

1) expressions

2) the difference between "expressions" and "general expressions"

3) Quoting.  The difference between "" and <>

4) "interpolating" as it refers to Perl (not math, where you "guess"
what a value is based on values on both sides of you).

Many thanks,
-T

Did a bad interpolation on a matrix once and the bad formula
turned out to be a sine wave which really messing up
interpolating based on it.  Chuckle!

Always a good idea to graph your formula before using it
to guess values!


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: Tip: assign a value to a hash using a variable as a key

[Brandon Allbery]

On Sat, Sep 30, 2017 at 7:44 PM, ToddAndMargo  wrote:

> On 09/30/2017 02:15 PM, Brandon Allbery wrote:
>
>> This concept gets reused enough that it's not separately described for
>> every place where it is used; the documentation would be impossible to
>> manage, almost as impossible to read, and often out of sync with itself if
>> every reused concept had to be fully explained everywhere it is used.
>>
>
> In this lies the problem I have with a lot of documentation.
> It is often written as a refresher for those who already
> familiar with the concepts.  Linux "man pages" are notorious
> for this.
>

There should have been a link to the section on quoting forms. Although,
last time I looked at that, it was a bit dense.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Tip: assign a value to a hash using a variable as a key

[ToddAndMargo]

On 09/30/2017 02:15 PM, Brandon Allbery wrote:
This concept gets reused enough that it's not separately described for 
every place where it is used; the documentation would be impossible to 
manage, almost as impossible to read, and often out of sync with itself 
if every reused concept had to be fully explained everywhere it is used.


In this lies the problem I have with a lot of documentation.
It is often written as a refresher for those who already
familiar with the concepts.  Linux "man pages" are notorious
for this.

A compromise would be to start simple and then proceed into
the complex.  Technical writing such as this is truly an
art form.

Re: Tip: assign a value to a hash using a variable as a key

[ToddAndMargo]

On 09/30/2017 02:15 PM, Brandon Allbery wrote:
Basically: < > is single quotes and treats variables and expressions as 
literals. << >> is double quotes and interpolates variables but not 
general expressions. And { } does no quoting at all and uses general 
expressions.



Thank you!

[perl #132185] [LTA] file tests and Failure do not interact as expected

[Sam S. via RT]

On Sat, 30 Sep 2017 13:47:22 -0700, allber...@gmail.com wrote:
> So I included at least one discussion in the ticket that was utterly
> pointless and left unread. At this point I'm just going to assume only
> half-exposing the underlying mechanism is considered a feature and I need
> to use a different language when it's not.

You mean the part about exposing different stat() error conditions?

A `Failure` wraps a typed exception, which you can get at by calling the 
`.exception` method on it:

my $is-file = do given $path.f -> $result {
with $result.?exception {
when X::IO::DoesNotExist { ... }
when ... { ... }
when ... { ... }
default  { ... }
}
$result.so
}

(...or by letting it throw and then using a CATCH block.)

Exceptions also have type-specific attributes which can hold further details to 
differentiate similar but different error conditions.

If file tests should be made to expose more fine-grained error states (probably 
a good idea), they can use those two mechanisms without the need to change 
anything about Failure or add new syntax.

PS: At the end of the day, "only half-exposing the underlying mechanism" of 
low-level operating-system APIs is to be expected though, for a high-level 
language that wants to be cross-platform and user-friendly. Getting full access 
to specific operating-system APIs is what third-party modules such as [1] are 
for. Thankfully, Perl 6's NativeCall interface makes them relatively easy to 
write.


---
[1] https://github.com/cspencer/perl6-posix

Re: Tip: assign a value to a hash using a variable as a key

[Brandon Allbery]

On Sat, Sep 30, 2017 at 5:08 PM, ToddAndMargo  wrote:

> On 09/30/2017 02:20 AM, Timo Paulssen wrote:
>
>> This doc page should help you a lot with this topic:
>>
>> https://docs.perl6.org/language/subscripts#Basics
>>
>>
> A little bit.  I had found that when I was researching.  It did not
> go into who to use a variable as a key value.
>

It does, but indirectly because it's based on single vs. double quoting and
refers you there. This concept gets reused enough that it's not separately
described for every place where it is used; the documentation would be
impossible to manage, almost as impossible to read, and often out of sync
with itself if every reused concept had to be fully explained everywhere it
is used.

Basically: < > is single quotes and treats variables and expressions as
literals. << >> is double quotes and interpolates variables but not general
expressions. And { } does no quoting at all and uses general expressions.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Any way to get hashes to loop in order?

[Brandon Allbery]

On Sat, Sep 30, 2017 at 5:00 PM, ToddAndMargo  wrote:

> On 09/29/2017 07:25 PM, Brandon Allbery wrote:
>
>> The point of a hash is that it computes hash values from its keys for
>> fast lookup,
>>
>
> Not me.  I use them to "organize" data all in one easy to look
> up place.  For example:
>

I am talking about data structures, not personal preferences. If you want
different behavior, use the appropriate data structure: a tree instead of a
hash. Unfortunately, Perl 6 doesn't currently have any tree data structures
in its core. There is a Map, which is what some other languages call their
tree-based structures, but in Perl 6 it's an immutable hash structure
instead.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Tip: assign a value to a hash using a variable as a key

[ToddAndMargo]

On 09/30/2017 02:20 AM, Timo Paulssen wrote:

This doc page should help you a lot with this topic:

https://docs.perl6.org/language/subscripts#Basics



A little bit.  I had found that when I was researching.  It did not
go into who to use a variable as a key value.

This is what I wrote myself:





Perl 6 Hashes (associative arrays):
References:
   https://docs.perl6.org/language/subscripts#Basics
   https://docs.perl6.org/type/Hash#:exists



Creating and populating:

my %y = ( 'aa'=>"AA", 'bb'=> "BB", 'cc'=>"CC", 'dd'=>"DD" );

$ perl6 -e 'my %x = (aaa => "x", b=>"y", c=>"z"); say %x;'
{aaa => x, b => y, c => z}

$ perl6 -e 'my %x = aaa => "x", b=>"y", c=>"z"; say %x;'
{aaa => x, b => y, c => z}

$ perl6 -e 'my %x = [aaa => "x", b=>"y", c=>"z"]; say %x;'
{aaa => x, b => y, c => z}

Assigning an array to the hash
$ perl6 -e 'my %x = [aaa => "x", b=>@["y","q","r"], c=>"z"]; push 
@(%x), ""; say %x; for @(%x) {say $_};'

{aaa => x, b => [y q r ], c => z}
y
q
r


Assigning a value based on a varaible as a key (use {} instead of <>):
# perl6 -e ' my %x = ( "a" => "A", "b" => "x", "c" => "C" );
 my $y="b";
 %x{$y}="BB";
 say %x;'

{a => A, b => BB, c => C}



Altering a value:
%x = "abc";

$ perl6 -e 'my %x = [aaa => "x", b=>"y", c=>"z"]; %x = "abc"; say %x;'
{a => abc, aaa => x, b => y, c => z}


Printing/reading a value:
my $y=%x;
say %x;

$ perl6 -e 'my %x = [aaa => "x", b=>"y", c=>"z"]; %x = "abc"; say %x;'
y


Looping:
for @x.kv -> $key, $value {do something};

$ perl6 -e 'my %x = [a => "x", b=>"r", c=>"z"]; say %x; for %x.kv -> 
$key, $value {say $key};'

{a => x, b => r, c => z}
a
c
b



code>
#!/usr/bin/perl6

my %y = ( 'aa'=>"AA", 'bb'=> "BB", 'cc'=>"CC", 'dd'=>"DD" );

print "loop of \%y\n";
for %y.kv -> $key, $value {
   print " \%y has an key of <$key> and a value of <$value>\n"; }
print "\n";


loop of %y
 %y has an key of  and a value of 
 %y has an key of  and a value of 
 %y has an key of  and a value of 
 %y has an key of  and a value of 


Passing Hashes to Subs:
$ perl6 -e 'sub SayHash(%H) {say %H}; my %x = [aaa => "x", b=>"y", 
c=>"z"];SayHash(%x);'

{aaa => x, b => y, c => z}



Destructuring Parameters (subs):
https://docs.perl6.org/type/Signature#index-entry-destructuring_arguments_%28Signature%29

sub all-dimensions(% (:length(:$x), :width(:$y), :depth(:$z))) {
$x andthen $y andthen $z andthen True }

And maybe:
sub foo(%bar (:length($)!, :width($)!)) {}





Adverbs:

Some methods are implemented as adverbs on subscripts.
:exists

The adverb :exists returns Bool::True if a key exists in the Hash. If 
more than one key is supplied it returns a List of Bool.


my %h = a => 1, b => 2;
say %h:exists;   # OUTPUT: «True␤»
say %h:exists; # OUTPUT: «(True True)␤»


:delete

Use :delete to remove a Pair from the Hash.

my %h = a => 1;
dd %h; # Hash %h = {:a(1)}
%h:delete;
dd %h; # Hash %h = {}


:p

The adverb :p returns a Pair or a List of Pair instead of just the value.

my %h = a => 1, b => 2;
say %h:p;# OUTPUT: «a => 1␤»
say %h:p;  # OUTPUT: «(a => 1 b=> 2)␤»


:v and :k

The adverbs :v and :k return the key or value or a list their of.

my %h = a => 1, b => 2;
say %h:k;# OUTPUT: «a␤»
say %h:k;  # OUTPUT: «(a b)␤»


You can also use the adverbs without knowing anything about the hash by 
using empty angle brackets in which case all the keys and values will be 
listed:


my %h1 = a => 1;
my %h2 = a => 1, b => 2;
say %h1<>:k; # OUTPUT: «(a)␤»
say %h1<>:v; # OUTPUT: «(1)␤»
say %h2<>:k; # OUTPUT: «(a b)␤»
say %h2<>:v; # OUTPUT: «(1 2)␤»

[perl #132183] Insufficient debug messages from zef/perl6.bat when package build fails

[via RT]

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


I downloaded and installed the latest Windows x64 build of Rakudo 
(http://rakudo.org/downloads/star/rakudo-star-latest-x86_64%20(JIT).msi). 
My operating system is Windows Server 2016.

When I try to install Inline::Perl5 with zef, the package installation 
fails. But no matter how high I set verbosity, all I get is a cryptic 
error message:

C:\Users\villek>zef --debug install Inline::Perl5
===> Searching for: Inline::Perl5
===> Found: Inline::Perl5:ver('0.29'):auth('github:niner') [via 
Zef::Repository::LocalCache]
===> Dependencies: LibraryMake, File::Temp
===> Filtering: Inline::Perl5:ver('0.29'):auth('github:niner')
===> Filtering [OK] for Inline::Perl5:ver('0.29'):auth('github:niner')
===> Building: Inline::Perl5:ver('0.29'):auth('github:niner')
Building with plugin: Zef::Service::Shell::Build+{}
Command: C:\rakudo\bin\perl6.bat -Ilib -I. -MBuild -e 
::('Build').new.build('C:\Users\villek\.zef\store\Inline-Perl5-0.29.tar.gz\Inline-Perl5-0.29');
 
exit(0);
Can't find string terminator '"' anywhere before EOF at -e line 1.

Perl 5 version requirement not met

   in method build at 
C:\Users\villek\.zef\store\Inline-Perl5-0.29.tar.gz\Inline-Perl5-0.29\Build.pm 
(Build) line 6
   in block  at -e line 1


===> Building [FAIL]: Inline::Perl5:ver('0.29'):auth('github:niner')
Aborting due to build failure: 
Inline::Perl5:ver('0.29'):auth('github:niner') (use --force-build to 
override)
   in code  at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 329
   in method build at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 294
   in sub  at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 520
   in method install at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 631
   in sub MAIN at 
C:\rakudo\share\perl6\site\sources\ED3033E8712BCF9F6DE53678B14A54705DF211A6 
(Zef::CLI) line 152
   in block  at 
C:\rakudo\share\perl6\site\resources\DC5F87DA28311BE6F3A731229527E5C4A2F12716 
line 1
   in sub MAIN at C:\rakudo\share\perl6\site\bin\zef line 2
   in block  at C:\rakudo\share\perl6\site\bin\zef line 2

This is in cmd.exe. In Powershell, the output is similar:

PS C:\Users\villek> zef --debug install Inline::Perl5
===> Searching for: Inline::Perl5
===> Found: Inline::Perl5:ver('0.29'):auth('github:niner') [via 
Zef::Repository::LocalCache]
===> Dependencies: LibraryMake, File::Temp
===> Filtering: Inline::Perl5:ver('0.29'):auth('github:niner')
===> Filtering [OK] for Inline::Perl5:ver('0.29'):auth('github:niner')
===> Building: Inline::Perl5:ver('0.29'):auth('github:niner')
Building with plugin: Zef::Service::Shell::Build+{}
Command: C:\rakudo\bin\perl6.bat -Ilib -I. -MBuild -e 
::('Build').new.build('C:\Users\villek\.zef\store\Inline-Perl5-0.29.tar.gz\Inline-Perl5-0.29');
 
exit(0);
Can't find string terminator '"' anywhere before EOF at -e line 1.

Perl 5 version requirement not met

   in method build at 
C:\Users\villek\.zef\store\Inline-Perl5-0.29.tar.gz\Inline-Perl5-0.29\Build.pm 
(Build) line 6
   in block  at -e line 1


===> Building [FAIL]: Inline::Perl5:ver('0.29'):auth('github:niner')
Aborting due to build failure: 
Inline::Perl5:ver('0.29'):auth('github:niner') (use --force-build to 
override)
   in code  at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 329
   in method build at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 294
   in sub  at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 520
   in method install at 
C:\rakudo\share\perl6\site\sources\3393EDA469A9E8925A633FF7A533AB41141495DA 
(Zef::Client) line 631
   in sub MAIN at 
C:\rakudo\share\perl6\site\sources\ED3033E8712BCF9F6DE53678B14A54705DF211A6 
(Zef::CLI) line 152
   in block  at 
C:\rakudo\share\perl6\site\resources\DC5F87DA28311BE6F3A731229527E5C4A2F12716 
line 1
   in sub MAIN at C:\rakudo\share\perl6\site\bin\zef line 2
   in block  at C:\rakudo\share\perl6\site\bin\zef line 2

Is this a bug in zef or in perl6.bat?

Am I expected to read through the source code on the lines mentioned in 
the stack trace?

It would be much more useful to see some diagnostics about which 
compiler the Build package is trying to use (if any!), whether it has 
failed to find it and what it is actually trying to accomplish.

Regards,
Ville Koskinen

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Sam S. via RT]

On Sat, 30 Sep 2017 13:13:31 -0700, c...@zoffix.com wrote:
> Don't see a reason why not.

Well, passing a 'type' string parameter to select between what is essentially 
different object sub-types, seems internal-ish.

I can't think of anything else in the public Perl 6 API which does this; a more 
Perl 6'ish API would dispatch based on *different* named parameters, or simply 
make the object sub-types available as separate subclasses.

So it might make sense to consider `Junction.new` as "not public API" for now, 
until this is ironed out.

> If it weren't, all fixed bugs still need a test to cover them.

Noted; Marking the ticket as TESTNEEDED.

A test for the current behavior could look like:

use Test;
throws-like { Junction.new }, X::Multi::NoMatch, "Junction.new with no 
arguments";

Re: Any way to get hashes to loop in order?

[ToddAndMargo]

On Sep 30, 2017 12:41 PM, "Parrot Raiser" <1parr...@gmail.com 
> wrote:


Prepending the real key value with an order indicator, then sorting
the retrieved list on the key would achieve that, (though the maximum
number size would have to be known in advance.

E.g. 001First_key => data1, 002Second => data2



On 09/30/2017 01:59 PM, Brock Wilcox wrote:
Maybe a list/array of pairs would be better, and then cast it to a hash 
if you need to do fast lookups.




I was going to create an "index" of the keys in an regular
array.  Then create the hash using the index.  When I
wanted to print things in order, loop on the index array,
not the hash.

Re: Any way to get hashes to loop in order?

[ToddAndMargo]

On 09/29/2017 07:25 PM, Brandon Allbery wrote:
The point of a hash is that it computes hash values from its keys for 
fast lookup,


Not me.  I use them to "organize" data all in one easy to look
up place.  For example:

my %SmtpIni = [
'DebugTrace' => "",
'smtp'   => "",
'port'   => "",
'username'   => "",
'password'   => "",
'from'   => "",
'to' => @[""],
'Subject'=> "",
'Text'   => "",
'FileName'   => @[""] ];

You will notice that all the smtp information is organized
in one variable for easy retrieval.  And that %SmtpIni
is absolutely obvious what password it refers to.  No guessing
involved.  No trying to figure out who goes to whom, especially
when using a global variables (which I try to keep to a minimum).

It is all about organization and readability for me, not speed.
If I wanted speed, I would go to the dark side and learn C.

The solution is to create and "index" of the hash and loop
on the index instead of the has if I want to see things in order.
That actually sounds like a fun code.

-T

Re: Any way to get hashes to loop in order?

[Brock Wilcox]

Maybe a list/array of pairs would be better, and then cast it to a hash if
you need to do fast lookups.

On Sep 30, 2017 12:41 PM, "Parrot Raiser" <1parr...@gmail.com> wrote:

> Prepending the real key value with an order indicator, then sorting
> the retrieved list on the key would achieve that, (though the maximum
> number size would have to be known in advance.
>
> E.g. 001First_key => data1, 002Second => data2
>

Re: [perl #132185] [LTA] file tests and Failure do not interact as expected

[Brandon Allbery]

On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT  wrote:

> To the extent that you're basing your expectations on the fact that a Perl
> 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without
> blowing up), well, that's just a matter of having to unlearn Perl 5 (or
> other programming languages) while learning Perl 6... :)
>

So I included at least one discussion in the ticket that was utterly
pointless and left unread. At this point I'm just going to assume only
half-exposing the underlying mechanism is considered a feature and I need
to use a different language when it's not.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #132185] [LTA] file tests and Failure do not interact as expected

[Brandon Allbery via RT]

On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT  wrote:

> To the extent that you're basing your expectations on the fact that a Perl
> 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without
> blowing up), well, that's just a matter of having to unlearn Perl 5 (or
> other programming languages) while learning Perl 6... :)
>

So I included at least one discussion in the ticket that was utterly
pointless and left unread. At this point I'm just going to assume only
half-exposing the underlying mechanism is considered a feature and I need
to use a different language when it's not.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

[perl #132185] [LTA] file tests and Failure do not interact as expected

[Sam S. via RT]

I agree with Zoffix that this seems to be fine as is.

Generally speaking, IO operations that logically require an existing path will 
return a Failure if the path does not in fact exist:

  Slurp its content? Failure.
  Rename/move/copy it? Failure.
  Check its size? Failure.
  Check if it is of type "directory? Failure.
  Check if it is of type "file"? Failure.

Whereas `.e`, i.e. checking if a path exists, is by necessity *not* an 
operation that assumes an existing path.

The only thing that might be debatable, is whether `.f` should mean:

   a) Check if it is of type "file".

   b) Check if it exists, and if so, if is of type "file".

The current behavior (a) seems more natural and useful to me though.

Perl 5 does (a) as well, in the sense that it too distinguishes "failure" from 
"no" in the return value:

 - "yes, it is of type 'file'":  a defined truthy value
 - "no, it is not of type 'file'":  a defined falsy value
 - "failure, it does not exist so its type can not be checked":  `undef`

Perl 6 merely improves on that by promoting the failure condition from `undef` 
to `Failure`, which both carries more information and provides more safety by 
default.

To the extent that you're basing your expectations on the fact that a Perl 5 
`undef` can be used in ways that a Perl 6 `Failure` cannot (without blowing 
up), well, that's just a matter of having to unlearn Perl 5 (or other 
programming languages) while learning Perl 6... :)

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Zoffix Znet via RT]

On Sat, 30 Sep 2017 12:28:48 -0700, sml...@gmail.com wrote:
> Is `Junction.new` meant to be public API?

Don't see a reason why not.

> If not, do we still need a test for this?

If it weren't, all fixed bugs still need a test to cover them. If the test 
should
not become part of the spec, it should be placed into rakudo's test suite 
instead.


> ---
> [1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284
> [2] https://github.com/rakudo/rakudo/commit/61ecfd511

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Zoffix Znet via RT]

On Sat, 30 Sep 2017 12:28:48 -0700, sml...@gmail.com wrote:
> Is `Junction.new` meant to be public API?

Don't see a reason why not.

> If not, do we still need a test for this?

If it weren't, all fixed bugs still need a test to cover them. If the test 
should
not become part of the spec, it should be placed into rakudo's test suite 
instead.


> ---
> [1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284
> [2] https://github.com/rakudo/rakudo/commit/61ecfd511

Re: Perl 6 Object Construction - General Advice

[Brian Duggan]

On Saturday, September 30, Mark Devine wrote: 
> My most common OC case:  initialize attributes at OC time from external
> input that will be parsed with grammars &/| scrubbed with elaborate
> conditional tests.

I like to use assignment for simple things and TWEAK for
complicated things --

class Foo {
has $.bar = 'something simple';
has $.baz;
submethod TWEAK {
$!baz = call-something-complicated;
}
}

Brian

[perl #125251] Usage does not print required type for positional params in MAIN

[Salve J. Nilsen via RT]

I think this bug can be closed.

Here's my reasoning. For me, a major point with the auto-generated usage text 
is that it helps the developer of the program see the importance of picking 
good variable names. If a dev chooses to name them $integer1 and $integer2 
(which are obviously horrible variable names because they tell nothing about 
what they will be used for), then the generated usage text *should* looks 
stupid. Garbage in, garbage out.

In the same way, if the name of the variable doesn't give an indication of the 
type (e.g. $age is a number), then the error is still with the developer and 
not the language.

This is a non-issue, and the ticket should be closed. :)


- Salve (who is looking through all tickets related to MAIN)

Wed, 27 May 2015 06:11:13 -0700 skrev b...@post.pl:
> > In the original report, an argument can be made that the programmer
> > ought to have made the program more useful by writing
> >
> > sub MAIN (Int $integer) { ... }
> 
> What if there are two integer params? MAIN (Int $integer1, Int
> $integer2) looks bad and subroutine body may be hard to understand.
> We already have typed variable and choosing variable name to duplicate
> type name just to display this information to caller is redundant.
> 
> Despite that I found another inconsistency in positional params -
> anonymous one still display types:
> 
> $ perl6 -e 'sub MAIN (Int, Str) { ... }'
> Usage:
>   -e '...'  
> 
> 
> Maybe more consistent way of displaying types would be "--age=
> --name=" for named and "age name" for named positionals
> and " " for anonymous positionals?
> 
> 
> 
> 
> > On 26 May 2015, at 20:01, Patrick R. Michaud via RT  > follo...@perl.org> wrote:
> >
> > On Tue May 26 08:38:30 2015, b...@post.pl wrote:
> >> I think this is bug because type is more important than irrelevant
> >> variable name.
> >> Expected output is: "Usage:␤  /tmp/tmpfile "
> >
> > In this case, the variable name is "irrelevant" primarily because the
> > programmer chose an irrelevant name.  A clearer case for the current
> > behavior comes from
> >
> > sub MAIN (Int $count!) { ... }
> >
> > which produces a more useful  "Usage:␤  /tmp/tmpfile "
> > message.
> >
> > Or consider a grep-like replacement:
> >
> > sub MAIN ($pattern!, @*files) { ... }
> >
> > that produces "Usage:␤  /tmp/tmpfile  [ ...]".
> >
> >
> > In the original report, an argument can be made that the programmer
> > ought to have made the program more useful by writing
> >
> > sub MAIN (Int $integer) { ... }
> >
> > which outputs "Usage:␤  /tmp/SJk_VxNAxM ".
> >
> > I'm inclined to reject this ticket, but will leave it open for
> > further discussion.
> >
> > Pm
> >
> >
> >
> >

[perl #131395] Using a cross meta operator on an empty list complains about not supporting elems

[Sam S. via RT]

On Mon, 29 May 2017 11:36:49 -0700, c...@zoffix.com wrote:
> On Mon, 29 May 2017 10:02:27 -0700, thunderg...@comcast.net wrote:
> > Using a cross meta operator on an empty list complains "This type 
> > (Scalar) does not support elems".
> > 
> >  say (1,2).elems; say ().elems; say (1,2) X ();
> > 
> > yields "2␤0␤This type (Scalar) does not support elems"
> > 
> > Seems to work correctly with arrays instead of lists.
> > 
> >  say [1,2].elems; say [].elems; say [1,2] X [];
> > 
> > 
> > Linux Mint 17.2
> > 
> >  >perl6 -v
> >  >This is Rakudo version 2017.05 built on MoarVM version 2017.05 
> > implementing Perl 6.c.
> 
> 
> Thank you for the report. lizmat++ fixed the issue.
> 
> Fix: https://github.com/rakudo/rakudo/commit/9494cbd3b9
> Test: https://github.com/perl6/roast/commit/0faf3c354f

Re-opening, because it hasn't been fixed for the Xop case yet:

➜  say () X+ (1, 2);
This type (Scalar) does not support elems

➜  say (1,2) X~ ();
This type (Scalar) does not support elems

➜  say () X=> ();
This type (Scalar) does not support elems

Bisectable¹ blames a commit² from January.


---
[1] https://gist.github.com/Whateverable/f1b3066f1e2c45df7ab5e0aa7aeee3a7
[2] https://github.com/rakudo/rakudo/commit/a26f51361

---
This is Rakudo version 2017.09-142-ga89add0bf built on MoarVM version 
2017.09.1-49-gb3dd812a
implementing Perl 6.c.

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Sam S. via RT]

On Fri, 02 Jun 2017 18:58:22 -0700, c...@zoffix.com wrote:
> While chasing some other bugs, came across this one:
> 
>  m: Junction.new.BUILDALL: {}
>  rakudo-moar ef9872: OUTPUT: «This type (Scalar) does not
> support elems␤  in block  at  line 1␤␤»
> 
> Not sure how much it matters in itself, but figured I'd report it, in
> case it's a symptom of a bigger bug.

This can be golfed to just:

Junction.new;

And it has been fixed to throw a better error message now:

➜  Junction.new;
Cannot resolve caller new(Junction: ); none of these signatures match:
(Junction $: \values, Str :$type!, *%_)
(Junction $: Str:D \type, \values, *%_)

According to bisectable¹, it was fixed by a commit² in June.

The 'bigger issue' was possibly RT #131395.

Is `Junction.new` meant to be public API?
If not, do we still need a test for this?

---
[1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284
[2] https://github.com/rakudo/rakudo/commit/61ecfd511

Perl 6 Object Construction - General Advice

[Mark Devine]

Perl 6,

I am preparing to write several classes for some Perl 6 apps I intend to craft 
in support of a prominent backup suite.  In looking at the documentation & some 
of the modules published in the Perl 6 ecosystem, I’m not quite sure that I can 
identify the best idiomatic object construction (OC) approach for my most 
frequent cases that will stand the test of time.  I don’t want to start writing 
too many of these using my baby/teenager-Perl6 skills and then go back and 
refactor ALL of them later with better OC approaches as I learn more.  I’d like 
to have a boilerplate OC construct that accommodates most cases, if it is 
possible to zero in on one.

My most common OC case:  initialize attributes at OC time from external input 
that will be parsed with grammars &/| scrubbed with elaborate conditional tests.

Mu’s new() cannot assign to the class attributes, but BUILD can.  I’ve used 
that construct successfully, but I’m not convinced that will be the best 
approach for the long term.


OC: new() { self.bless() } – BUILD() still confuses me.  (I am hopeful for a 
future Perl 6 book with a 40-page chapter comprehensively detailing the 
responsibilities of each of these mechanisms.)  I’ve read 
https://docs.perl6.org/language/classtut & 
https://docs.perl6.org/language/objects#Object_Construction, but I’m not 
getting it all.

I’ve tried multiple approaches to initializing variables with defaults, 
sometimes failing at compile time when I attempt to do it in the wrong place.  
Other times, as I move things around, I break default assignments (I.e. has 
$.var = ‘/tmp’) that worked magically using Mu’s new().  I am still learning by 
experimentation…

The Perl 6 ecosystem has lots of clever OC constructs, but I’m still not able 
to infer which I could boilerplate into an “80%-of-the-time-go-to” OC.

I just recently encountered this construct in more than one module (I.e. 
https://github.com/sergot/io-socket-ssl/blob/master/lib/IO/Socket/SSL.pm6):



method new(*%args is copy) {

…# fiddle with the %args hash as required, but obviously not 
attributes here

self.bless(|%args)!initialize;

}



method !initialize {

…# directly initialize attributes with conditional logic

self;

}



Is this construct a bona-fide industrial-strength Perl 6 OC idiom that I could 
employ with confidence?  Should I keep looking?Also, in this OC approach, 
I’m not quite seeing how |%args (I.e. with %args = ‘example.com’) ends up 
magically as $!host (I.e. =’example.com’) in initialize().  I’ll need just a 
bit more explanation to understand it.



If anyone can provide more detail on the 
mechanics/expectations/responsibilities/idioms of Perl 6 OC (new() { 
self.bless() } – BUILD() & more), I would appreciate your input.  All educated 
advice is welcome.

Thanks,

Mark

[perl #132109] [BUG] `.skip` on a sequence starting with a `Slip`, returns a corrupted `Seq`

[Zoffix Znet via RT]

On Sat, 16 Sep 2017 22:29:57 -0700, sml...@gmail.com wrote:
> When calling `.skip` on a list which contains a `Slip` at the start, the 
> resulting `Seq` behaves in some cases as if *all* elements from that 
> `Slip` were skipped (instead of just the first one):
> 
>  say (, ).map(|*).skip.perl;# ("d", "e").Seq
>  say (, ).map(|*).skip.eager.perl;  # ("d", "e").Seq
>  say (, ).map(|*).skip.eager.gist;  # (d e)
>  say (, ).map(|*).skip.eager.join;  # de
>  say (, ).map(|*).skip.cache.perl;  # ("d", "e")
>  say (, ).map(|*).skip.cache.join;  # de
>  say (, ).map(|*).skip.[*].gist;# (d e)
> 
> But it depends on how the returned `Seq` is iterated. In the following 
> cases it behaves correctly:
> 
>  say (, ).map(|*).skip.gist;   # (b c d e)
>  say (, ).map(|*).skip.join;   # bcde
>  say (, ).map(|*).skip.cache.gist; # (b c d e)
>  say (, ).map(|*).skip.[0..*].gist;# (b c d e)
>  say (, ).map(|*).skip.iterator.pull-one;  # b
> 
> It looks like¹ this bug has existed ever since the `.skip` method was 
> implemented² in January 2017.
> 
> ---
> [1] https://gist.github.com/Whateverable/973c1b6cb09af28a2249b4ba33165885
> [2] https://github.com/rakudo/rakudo/commit/8a6bfc6
> 
> ---
> This is Rakudo version 2017.08-156-ge6a695b27 built on MoarVM version 
> 2017.08.1-171-gcf95892e
> implementing Perl 6.c.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/41896b7bbf9fe5a
Test: https://github.com/perl6/roast/commit/2e23965fa1180b732

[perl #132109] [BUG] `.skip` on a sequence starting with a `Slip`, returns a corrupted `Seq`

[Zoffix Znet via RT]

On Sat, 16 Sep 2017 22:29:57 -0700, sml...@gmail.com wrote:
> When calling `.skip` on a list which contains a `Slip` at the start, the 
> resulting `Seq` behaves in some cases as if *all* elements from that 
> `Slip` were skipped (instead of just the first one):
> 
>  say (, ).map(|*).skip.perl;# ("d", "e").Seq
>  say (, ).map(|*).skip.eager.perl;  # ("d", "e").Seq
>  say (, ).map(|*).skip.eager.gist;  # (d e)
>  say (, ).map(|*).skip.eager.join;  # de
>  say (, ).map(|*).skip.cache.perl;  # ("d", "e")
>  say (, ).map(|*).skip.cache.join;  # de
>  say (, ).map(|*).skip.[*].gist;# (d e)
> 
> But it depends on how the returned `Seq` is iterated. In the following 
> cases it behaves correctly:
> 
>  say (, ).map(|*).skip.gist;   # (b c d e)
>  say (, ).map(|*).skip.join;   # bcde
>  say (, ).map(|*).skip.cache.gist; # (b c d e)
>  say (, ).map(|*).skip.[0..*].gist;# (b c d e)
>  say (, ).map(|*).skip.iterator.pull-one;  # b
> 
> It looks like¹ this bug has existed ever since the `.skip` method was 
> implemented² in January 2017.
> 
> ---
> [1] https://gist.github.com/Whateverable/973c1b6cb09af28a2249b4ba33165885
> [2] https://github.com/rakudo/rakudo/commit/8a6bfc6
> 
> ---
> This is Rakudo version 2017.08-156-ge6a695b27 built on MoarVM version 
> 2017.08.1-171-gcf95892e
> implementing Perl 6.c.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/41896b7bbf9fe5a
Test: https://github.com/perl6/roast/commit/2e23965fa1180b732

Re: Tip: assign a value to a hash using a variable as a key

[Timo Paulssen]

This doc page should help you a lot with this topic:

https://docs.perl6.org/language/subscripts#Basics

Tip: assign a value to a hash using a variable as a key

[ToddAndMargo]

Hi All,

This one about killed me to find!  The guys on the chat line
figured it out for me.  Apparently some tutorial is wrong on
this too, but I couldn't figure out which one they were
referring to.

When assigning a value to a hash using a variable as the key,
use {} instead of <>


perl6 -e ' my %x = ( "a" => "A", "b" => "x", "c" => "C" );
   my $y="b";
   %x{$y}="BB"; say %x;'

{a => A, b => BB, c => C}


Wow.  I never would have guessed that one!
-T

[perl #126092] pairs X pairs can't bind to subsig

[Sam S. via RT]

On Fri, 18 Sep 2015 00:51:42 -0700, larry wrote:
> 00:13 < TimToady> m: for (1,2,3).pairs X (4,5,6).pairs -> ($x,$y) { say "$x
> $y" }
> 00:13 <+camelia> rakudo-moar c0e0c9: OUTPUT«This type cannot unbox to a
> native string␤  in block  at /tmp/YnA_LhZbRO:1␤␤»

It gives a nicer error message now:

➜  for (1,2,3).pairs X (4,5,6).pairs -> ($x,$y) { say "$x $y" };
Too few positionals passed to ''; expected 2 arguments but got 0 in 
sub-signature
  in block  at -e line 1

The reason for the error is that sub-signatures use `.Capture`, and 
`List.Capture` turns Pair elements into named arguments:

➜  dd (a => 1, 42, b => 2).Capture;
\(42, :a(1), :b(2))

I too have got bitten by this trap before - it essentially makes it unsafe to 
pass lists containing Pair objects to code (think e.g. a third-party module) 
that expects arbitrary lists of objects, unless you can ensure that the code 
doesn't and never will end up binding the list to a sub-signature (or otherwise 
calling `.Capture` on it).

It's IMO also conceptually dubious. A List firmly represents the concept of 
"list of positional elements", and I see no compelling conceptual reason why 
`.Capture` should second-guess this meaning based on the *type* of the list 
elements.

So I can only assume that it works like it does now, for practical reasons - 
i.e. because something in core relies, or used to rely, on it working this way. 
But what?

Note that flattening things into argument lists *doesn't* suffer from this 
issue, because instead of `.Capture` it uses `.FLATTENABLE_LIST` + 
`.FLATTENABLE_HASH` which always cleanly treat list elements as positionals and 
hash entries as nameds.

Marking this ticket as [@LARRY].