Re: Objects, TWEAK and return

[yary]

Agreed!
-y


On Mon, Mar 22, 2021 at 6:45 PM Ralph Mellor 
wrote:

> On Mon, Mar 22, 2021 at 2:12 PM yary  wrote:
> >
> > It's not good practice to use "map" for side effects only, discarding
> > the returned value–which happens here
>
> I agree.
>
> > Would [using `for`] also work-around the lack of sink context in TWEAK?
>
> Yes.
>
> > I think it is a cause of the unexpected behavior.
>
> Perhaps.
>
> That said, in response to the issue I filed in which I wrote:
>
> > BUILD and TWEAK are not called in sink context by the existing standard
> > object construction machinery shipping with standard Raku 6.d. Perhaps it
> > would be best if they were?
>
> jnthn has commented:
>
> > Yes, with a potential optimization of seeing if the BUILD or TWEAK
> already
> > declared its return type as Nil (which is a common practice) so we don't
> > increase code size of the generated BUILDALL without a need.
>
> --
> love raiph
>

Re: Objects, TWEAK and return

[Ralph Mellor]

On Mon, Mar 22, 2021 at 2:12 PM yary  wrote:
>
> It's not good practice to use "map" for side effects only, discarding
> the returned value–which happens here

I agree.

> Would [using `for`] also work-around the lack of sink context in TWEAK?

Yes.

> I think it is a cause of the unexpected behavior.

Perhaps.

That said, in response to the issue I filed in which I wrote:

> BUILD and TWEAK are not called in sink context by the existing standard
> object construction machinery shipping with standard Raku 6.d. Perhaps it
> would be best if they were?

jnthn has commented:

> Yes, with a potential optimization of seeing if the BUILD or TWEAK already
> declared its return type as Nil (which is a common practice) so we don't
> increase code size of the generated BUILDALL without a need.

--
love raiph

Re: Objects, TWEAK and return

[yary]

Good to see this investigated down to the details, yet I just realized
something that was bothering me about it. Going back to the original post:

 submethod TWEAK {
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
)  });
  }

It's not good practice to use "map" for side effects only, discarding the
returned value–which happens here, and I think it is a cause of the
unexpected behavior.

Would this also work-around the lack of sink context in TWEAK?

 submethod TWEAK {
for $!filelist.lines».split(',')  -> ($a, $b) { @!show.push: ( $a, $b
)  };
  }

-y


On Sun, Mar 21, 2021 at 7:11 PM Ralph Mellor 
wrote:

> On Sun, Mar 21, 2021 at 9:47 PM  wrote:
> >
> > Waw! :) Following your examples and suggestions, these work:
> >
> > > class { submethod TWEAK(-->Nil) { Any.map: {say 99}  } }.new;
> > > class { submethod TWEAK { sink Any.map: {say 99}  } }.new;
> > > class { submethod TWEAK { eager Any.map: {say 99}  } }.new;
> >
> > I really appreciate your discussion. Let me know if you think it
> > is worth to include this issue in the TWEAK Raku documentation.
>
> I think the first step is to see if it's considered a Raku(do) bug.
>
> I've filed an issue: https://github.com/rakudo/rakudo/issues/4260
>
> --
> love, raiph
>

Re: Objects, TWEAK and return

[Ralph Mellor]

On Sun, Mar 21, 2021 at 9:47 PM  wrote:
>
> Waw! :) Following your examples and suggestions, these work:
>
> > class { submethod TWEAK(-->Nil) { Any.map: {say 99}  } }.new;
> > class { submethod TWEAK { sink Any.map: {say 99}  } }.new;
> > class { submethod TWEAK { eager Any.map: {say 99}  } }.new;
>
> I really appreciate your discussion. Let me know if you think it
> is worth to include this issue in the TWEAK Raku documentation.

I think the first step is to see if it's considered a Raku(do) bug.

I've filed an issue: https://github.com/rakudo/rakudo/issues/4260

--
love, raiph

Re: Objects, TWEAK and return

[mimosinnet]

Waw! :) Following your examples and suggestions, these work:

> class { submethod TWEAK(-->Nil) { Any.map: {say 99}  } }.new;
> class { submethod TWEAK { sink Any.map: {say 99}  } }.new;
> class { submethod TWEAK { eager Any.map: {say 99}  } }.new;

I really appreciate your discussion. Let me know if you think it is worth
to include this issue in the TWEAK Raku documentation.

Thanks very much for the detailed explanation.

Cheers!


Missatge de Ralph Mellor  del dia dg., 14 de març
2021 a les 23:00:

> On Sun, Mar 14, 2021 at 2:12 AM Brad Gilbert  wrote:
> >
> > Ralph, the last value in all functions are not sunk by default,
> > so of course the last one in `TWEAK` is not sunk by default.
>
> Right. Thanks for correcting this misleading part of my explanation.
>
> > The bug is that the calling code is not sinking the result.
>
> The code that normally calls BUILD and TWEAK is shipped with
> standard Raku settings. It isn't sinking the result. That sounds like
> a bug to me. Though perhaps it's not one worth considering fixing
> this side of RakuAST landing with its new sink handling code that
> will, with luck, have higher performance.
>
> (That is what I was trying to say, but it was 3am...)
>
> --
> love, raiph
>

Re: Objects, TWEAK and return

[Ralph Mellor]

On Sun, Mar 14, 2021 at 2:12 AM Brad Gilbert  wrote:
>
> Ralph, the last value in all functions are not sunk by default,
> so of course the last one in `TWEAK` is not sunk by default.

Right. Thanks for correcting this misleading part of my explanation.

> The bug is that the calling code is not sinking the result.

The code that normally calls BUILD and TWEAK is shipped with
standard Raku settings. It isn't sinking the result. That sounds like
a bug to me. Though perhaps it's not one worth considering fixing
this side of RakuAST landing with its new sink handling code that
will, with luck, have higher performance.

(That is what I was trying to say, but it was 3am...)

--
love, raiph

Re: Objects, TWEAK and return

[Brad Gilbert]

Ralph, the last value in all functions are not sunk by default, so of
course the last one in `TWEAK` is not sunk by default.
This is intended behaviour.

It is up to the code that calls a function to sink the result if that is
the desired behaviour.

sub foo {
'a b c'.words».uc.map: *.say;
}

my $ = foo(); # nothing is printed

sink foo(); # «A␤B␤C␤» is printed

The bug is that the calling code is not sinking the result.


On Sat, Mar 13, 2021 at 8:05 PM Ralph Mellor 
wrote:

> Here's a golf:
>
> class { submethod TWEAK  { Any.map: {say 99} } }.new; #
> class { submethod TWEAK  { Any.map: {say 99}; 42 } }.new; # 99
> class { submethod TWEAK (--> 42) { Any.map: {say 99} } }.new; # 99
>
> The last line in a `BUILD` or `TWEAK` submethod is not eagerly evaluated
> by default.
>
> That sounds like a bug to me. But if not, and in the meantime,
> because your `$!filelist.lines...` line is the last one in your `TWEAK`
> submethod, the `@!show` array is being left empty, so the value to
> the right of `%` evaluates to zero, hence the error message you're seeing.
>
> On Sat, Mar 13, 2021 at 8:30 PM  wrote:
> >
> > Hi,
> >
> > When working with this week challenge for the PerlWeeklyChallenge, I
> noticed this behaviour with TWEAK:
> >
> > This does not work:
> >   submethod TWEAK {
> > $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a,
> $b )  });
> >   }
> >
> > This works:
> >   submethod TWEAK {
> > $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a,
> $b )  });
> > return;
> >   }
> >
> > It also works with other commands instead of 'return' (like assigning a
> value to a variable). From the examples in the documentation, I am not
> certain this is the expected behaviour.
> >
> > Thanks for this extraordinary language,
> >
> > Joan
> >
> >
> > P.S: This is the context where the command appears.  Apologies for the
> messy-Raku,
> > --
> > use Test;
> >
> > my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast
> date: 1937-07-23)"
> > 1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
> > 1723781,"Les Miserables Episode 3: The Trial (broadcast date:
> 1937-08-06)"
> > 1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
> > 1646043,"Les Miserables Episode 5: The Grave (broadcast date:
> 1937-08-20)"
> > 1714640,"Les Miserables Episode 6: The Barricade (broadcast date:
> 1937-08-27)"
> > 1714640,"Les Miserables Episode 7: Conclusion (broadcast date:
> 1937-09-03)"';
> >
> > class Movies {
> >
> >   has $.starttime;
> >   has $.currenttime;
> >   has $.filelist;
> >   has @!show; # ( [ time, show ] )
> >
> >   submethod TWEAK {
> > # miliseconds -> seconds
> > $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a,
> $b )  });
> > return;
> >   }
> >
> >   method what-show() {
> > my $position =  ( $!currenttime - $!starttime ) %
> @!show[*;0].sum/1000;
> > my ($time, $show);
> > for @!show[*;0] -> $show-time {
> >   $time += $show-time;
> >   return @!show[$show++;1] if $time > $position;
> > }
> >   }
> > }
> >
> > my $mv = Movies.new(
> >   starttime   => '1606134123',
> >   currenttime => '1614591276',
> >   filelist=> $data
> > );
> >
> > is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast
> date: 1937-07-23)"';
>

Re: Objects, TWEAK and return

[Ralph Mellor]

Here's a golf:

class { submethod TWEAK  { Any.map: {say 99} } }.new; #
class { submethod TWEAK  { Any.map: {say 99}; 42 } }.new; # 99
class { submethod TWEAK (--> 42) { Any.map: {say 99} } }.new; # 99

The last line in a `BUILD` or `TWEAK` submethod is not eagerly evaluated
by default.

That sounds like a bug to me. But if not, and in the meantime,
because your `$!filelist.lines...` line is the last one in your `TWEAK`
submethod, the `@!show` array is being left empty, so the value to
the right of `%` evaluates to zero, hence the error message you're seeing.

On Sat, Mar 13, 2021 at 8:30 PM  wrote:
>
> Hi,
>
> When working with this week challenge for the PerlWeeklyChallenge, I noticed 
> this behaviour with TWEAK:
>
> This does not work:
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
>   }
>
> This works:
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
> return;
>   }
>
> It also works with other commands instead of 'return' (like assigning a value 
> to a variable). From the examples in the documentation, I am not certain this 
> is the expected behaviour.
>
> Thanks for this extraordinary language,
>
> Joan
>
>
> P.S: This is the context where the command appears.  Apologies for the 
> messy-Raku,
> --
> use Test;
>
> my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast date: 
> 1937-07-23)"
> 1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
> 1723781,"Les Miserables Episode 3: The Trial (broadcast date: 1937-08-06)"
> 1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
> 1646043,"Les Miserables Episode 5: The Grave (broadcast date: 1937-08-20)"
> 1714640,"Les Miserables Episode 6: The Barricade (broadcast date: 1937-08-27)"
> 1714640,"Les Miserables Episode 7: Conclusion (broadcast date: 1937-09-03)"';
>
> class Movies {
>
>   has $.starttime;
>   has $.currenttime;
>   has $.filelist;
>   has @!show; # ( [ time, show ] )
>
>   submethod TWEAK {
> # miliseconds -> seconds
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
> return;
>   }
>
>   method what-show() {
> my $position =  ( $!currenttime - $!starttime ) % @!show[*;0].sum/1000;
> my ($time, $show);
> for @!show[*;0] -> $show-time {
>   $time += $show-time;
>   return @!show[$show++;1] if $time > $position;
> }
>   }
> }
>
> my $mv = Movies.new(
>   starttime   => '1606134123',
>   currenttime => '1614591276',
>   filelist=> $data
> );
>
> is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast date: 
> 1937-07-23)"';

Re: Objects, TWEAK and return

[Brad Gilbert]

I think that this is caused because it is returning a ｢Sequence｣ that is
not getting sunk.
This is because the last value from a function is never sunk in that
function.

You could also use ｢eager｣ ｢sink｣ or follow it with ｢Nil｣ or some other
value (instead of ｢return｣)

eager $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: (
$a, $b )  });
sink $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a,
$b )  });
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )
 });  Nil
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )
 });  'some other value'

You can also make ｢TWEAK｣ return a ｢Nil｣ in the signature (or any
constant/literal).

submethod TWEAK (-->Nil) { … }

Since the last value in the function is never returned it is also sunk.

---

It might be a good idea if the code that calls ｢TWEAK｣ (and maybe ｢BUILD｣)
sinks any result that they get.
Or maybe it should only sink ｢Sequence｣ values.

There are good reasons for allowing a ｢submethod｣ to return a value that
doesn't get sunk, so that should not change.

At any rate I don't think there is a bug in how ｢submethod TWEAK｣ is
compiled and run.
That part is working as intended.

On Sat, Mar 13, 2021 at 2:30 PM  wrote:

> Hi,
>
> When working with this week challenge for the PerlWeeklyChallenge
> , I noticed this behaviour with TWEAK:
>
> *This does not work:*
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
> )  });
>   }
>
> *This works:*
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
> )  });
> return;
>   }
>
> It also works with other commands instead of 'return' (like assigning a
> value to a variable). From the examples in the documentation, I am not
> certain this is the expected behaviour.
>
> Thanks for this extraordinary language,
>
> Joan
>
>
> P.S: This is the context where the command appears.  Apologies for the
> messy-Raku,
> --
> use Test;
>
> my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast date:
> 1937-07-23)"
> 1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
> 1723781,"Les Miserables Episode 3: The Trial (broadcast date: 1937-08-06)"
> 1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
> 1646043,"Les Miserables Episode 5: The Grave (broadcast date: 1937-08-20)"
> 1714640,"Les Miserables Episode 6: The Barricade (broadcast date:
> 1937-08-27)"
> 1714640,"Les Miserables Episode 7: Conclusion (broadcast date:
> 1937-09-03)"';
>
> class Movies {
>
>   has $.starttime;
>   has $.currenttime;
>   has $.filelist;
>   has @!show; # ( [ time, show ] )
>
>   submethod TWEAK {
> # miliseconds -> seconds
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
> )  });
> return;
>   }
>
>   method what-show() {
> my $position =  ( $!currenttime - $!starttime ) % @!show[*;0].sum/1000;
> my ($time, $show);
> for @!show[*;0] -> $show-time {
>   $time += $show-time;
>   return @!show[$show++;1] if $time > $position;
> }
>   }
> }
>
> my $mv = Movies.new(
>   starttime   => '1606134123',
>   currenttime => '1614591276',
>   filelist=> $data
> );
>
> is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast date:
> 1937-07-23)"';
>

Re: Objects, TWEAK and return

[Vadim Belman]

At the first glance it looks like bug. Possibly a result of over-optimization. 
Worth opening an issue at https://github.com/rakudo/rakudo/issues

Best regards,
Vadim Belman

> On Mar 13, 2021, at 3:29 PM, mimosin...@gmail.com wrote:
> 
> Hi,
> 
> When working with this week challenge for the PerlWeeklyChallenge 
> , I noticed this behaviour with TWEAK:
> 
> This does not work:
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
>   }
> 
> This works:
>   submethod TWEAK {
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
> return;
>   }
> 
> It also works with other commands instead of 'return' (like assigning a value 
> to a variable). From the examples in the documentation, I am not certain this 
> is the expected behaviour.
> 
> Thanks for this extraordinary language,
> 
> Joan
> 
> 
> P.S: This is the context where the command appears.  Apologies for the 
> messy-Raku, 
> --
> use Test;
> 
> my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast date: 
> 1937-07-23)"
> 1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
> 1723781,"Les Miserables Episode 3: The Trial (broadcast date: 1937-08-06)"
> 1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
> 1646043,"Les Miserables Episode 5: The Grave (broadcast date: 1937-08-20)"
> 1714640,"Les Miserables Episode 6: The Barricade (broadcast date: 1937-08-27)"
> 1714640,"Les Miserables Episode 7: Conclusion (broadcast date: 1937-09-03)"';
> 
> class Movies {
> 
>   has $.starttime;
>   has $.currenttime;
>   has $.filelist;
>   has @!show; # ( [ time, show ] )
> 
>   submethod TWEAK {
> # miliseconds -> seconds
> $!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b )  
> });
> return;
>   }
> 
>   method what-show() {
> my $position =  ( $!currenttime - $!starttime ) % @!show[*;0].sum/1000;
> my ($time, $show);
> for @!show[*;0] -> $show-time {
>   $time += $show-time;
>   return @!show[$show++;1] if $time > $position;
> }
>   }
> }
> 
> my $mv = Movies.new( 
>   starttime   => '1606134123',
>   currenttime => '1614591276',
>   filelist=> $data
> );
> 
> is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast date: 
> 1937-07-23)"';

Objects, TWEAK and return

[mimosinnet]

Hi,

When working with this week challenge for the PerlWeeklyChallenge
, I noticed this behaviour with TWEAK:

*This does not work:*
  submethod TWEAK {
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
)  });
  }

*This works:*
  submethod TWEAK {
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
)  });
return;
  }

It also works with other commands instead of 'return' (like assigning a
value to a variable). From the examples in the documentation, I am not
certain this is the expected behaviour.

Thanks for this extraordinary language,

Joan


P.S: This is the context where the command appears.  Apologies for the
messy-Raku,
--
use Test;

my $data = '1709363,"Les Miserables Episode 1: The Bishop (broadcast date:
1937-07-23)"
1723781,"Les Miserables Episode 2: Javert (broadcast date: 1937-07-30)"
1723781,"Les Miserables Episode 3: The Trial (broadcast date: 1937-08-06)"
1678356,"Les Miserables Episode 4: Cosette (broadcast date: 1937-08-13)"
1646043,"Les Miserables Episode 5: The Grave (broadcast date: 1937-08-20)"
1714640,"Les Miserables Episode 6: The Barricade (broadcast date:
1937-08-27)"
1714640,"Les Miserables Episode 7: Conclusion (broadcast date:
1937-09-03)"';

class Movies {

  has $.starttime;
  has $.currenttime;
  has $.filelist;
  has @!show; # ( [ time, show ] )

  submethod TWEAK {
# miliseconds -> seconds
$!filelist.lines».split(',').map( -> ($a, $b) { @!show.push: ( $a, $b
)  });
return;
  }

  method what-show() {
my $position =  ( $!currenttime - $!starttime ) % @!show[*;0].sum/1000;
my ($time, $show);
for @!show[*;0] -> $show-time {
  $time += $show-time;
  return @!show[$show++;1] if $time > $position;
}
  }
}

my $mv = Movies.new(
  starttime   => '1606134123',
  currenttime => '1614591276',
  filelist=> $data
);

is $mv.what-show, '"Les Miserables Episode 1: The Bishop (broadcast date:
1937-07-23)"';

Re: classes and objects questions

[ToddAndMargo via perl6-users]

On 12/14/20 2:33 PM, ToddAndMargo via perl6-users wrote:

Hi All,

https://docs.raku.org/language/classtut

  "A tutorial about creating and using classes
  in Raku"

So far so good.

  "Raku has a rich built-in syntax for defining
  and using classes."

U. Forgot something did we?  What is a "class"?


Next up:

  "A default constructor allows the setting of
  attributes for the created object:"

U.  Forgot something else, did we?  What is
an "object"?


The "tutorial" leaves "class" and "object" up to
the reader to guess at from what looks like an
interesting example.


But, again forgetting things, The tutorial also
leaves the syntax up for guess work as well.  Not
described are "$.", "$!", ":$", ^$" what are they
and what are the rules for using them.

Next up:

  my $r = Rectangle.new(
   lower => Point.new(x => 0, y => 0),
   upper => Point.new(x => 10, y => 10));


Why are we using ".new"?

Why are we using the syntax for a hash (=>)?

And:
  $!upper.x

What is the rules and purpose for such?  Why
the "!" and why the "."?


I do realize the documentation is not meant for
beginners, but rather a refresher for advanced
users that do not need it, but this link definitely
said "tutorial" -- fifth word in.

Would some kind soul please fill in the missing
parts of the "tutorial" for me?

Many thanks,
-T



Well, so far I have:

"class" is a definition of a custom structure of
of variables.

"object" is when you declare a structure using
a "class".

And I am still working on a "method" definition,
and where they fit into the classes declaration,
although I use methods extensively

say (-5..5).rand.truncate.abs**3
64

This is Perl 5's definition of method:
class method

A method whose invocant is a package name, not
an object reference. A method associated with
the class as a whole.

Not sure how to translate that to Raku

Re: classes and objects questions

[ToddAndMargo via perl6-users]

On 12/14/20 2:33 PM, ToddAndMargo via perl6-users wrote:

Hi All,

https://docs.raku.org/language/classtut

  "A tutorial about creating and using classes
  in Raku"

So far so good.

  "Raku has a rich built-in syntax for defining
  and using classes."

U. Forgot something did we?  What is a "class"?


Next up:

  "A default constructor allows the setting of
  attributes for the created object:"

U.  Forgot something else, did we?  What is
an "object"?


The "tutorial" leaves "class" and "object" up to
the reader to guess at from what looks like an
interesting example.


But, again forgetting things, The tutorial also
leaves the syntax up for guess work as well.  Not
described are "$.", "$!", ":$", ^$" what are they
and what are the rules for using them.

Next up:

  my $r = Rectangle.new(
   lower => Point.new(x => 0, y => 0),
   upper => Point.new(x => 10, y => 10));


Why are we using ".new"?

Why are we using the syntax for a hash (=>)?

And:
  $!upper.x

What is the rules and purpose for such?  Why
the "!" and why the "."?


I do realize the documentation is not meant for
beginners, but rather a refresher for advanced
users that do not need it, but this link definitely
said "tutorial" -- fifth word in.

Would some kind soul please fill in the missing
parts of the "tutorial" for me?

Many thanks,
-T



Okay, here are some Perl 5 definitions for PerlDocs:

https://perldoc.perl.org/perlglossary

class

    A user-defined type, implemented in Perl via a package that 
provides (either directly or by inheritance) methods (that is, 
subroutines) to handle instances of the class (its objects). See also 
inheritance.



class method

A method whose invocant is a package name, not an object reference. 
A method associated with the class as a whole. Also see instance method.



object

An instance of a class. Something that “knows” what user-defined 
type (class) it is, and what it can do because of what class it is. Your 
program can request an object to do things, but the object gets to 
decide whether it wants to do them or not. Some objects are more 
accommodating than others.



Anyone want to add Raku modifications to the above?  I
like their "user-defined type" description.

I don't know what to make of "more accommodating than others".


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

Re: classes and objects questions

[ToddAndMargo via perl6-users]

On 12/15/20 12:34 AM, WFB wrote:



JJ may be right about the OO thing, but it makes the
tutorial pretty much useless.  How "class" and "object"
*relate* to Raku needs to be explained.


When we are talking about describing Classes and Objects in a few words, 
then I agree. Searching on the web reveals lots of tutorials for Java, 
C# and so on with at least a few words about what classes and objects are.



"The best is the enemy of the good".  It is better to
slum it a bit and make the tutorial useful. JJ will
hate it, but he will live.

I don't think JJ hates useful tutorials. But he has to find a balance. 
Look in the Raku/doc repository 
<https://github.com/Raku/doc/graphs/commit-activity>. Every week ~15 
commits. And most of them on Sunday. Of course you can spend all day and 
make the classtut perfect, at least what is your understanding of 
perfect. But there is a lot more to be documented and maintained. You 
have to find a level of detail that provides information for all readers 
and to have only a limited amount of time and resources. That is JJ 
trying to do.
You are trying to shape the documentation for your needs. Sometimes the 
best documentation is not your documentation.
In this case adding links for the Variables and a few sentences about 
classes and objects would probably not hurt but I would listen to the 
arguments JJ has. Because he knows the big pictures.


Best


I like Parrots idea about using links, so advanced
users don't have to wade through  what they already
know and the rest of us can figure out what is going
on.

I have been looking at some Perl 5 Class tutorials
to try to get a hang on what is going on.  But since
we do not have reference pointers ...

Re: classes and objects questions

[ToddAndMargo via perl6-users]

On 12/15/20 7:00 AM, Parrot Raiser wrote:

Raku allows for several different programming paradigms; procedural,
functional, (as in languages like LISP), and object-oriented. It is
possible to write purely procedural Raku, while ignoring O-O features
completely, though it does take some dodging.

Object-oriented.programming first surfaced in the mid 1960s in
research projects, but was more generally visible by 1980. Like all
new programming concepts, it was going to cure cancer, bring about
world peace, and produce bug-free software. (And didn't, of course.)
It naturally had its specialised jargon, designed to ensure tribal
solidarity and repel infidels. It gradually spread with languages like
C++, (1979-83),  but remained a niche concept until Sun introduced
Java in 1995.

https://www.indeed.com/career-advice/career-development/what-is-object-oriented-programming

With the success of Java, later Javascript, and other new languages,
O-O and its jargon became
sufficiently mainstream that even many programmers working with other
languages learned the terminology. I suspect that many programmers
trained since the mid-90s assume that it's the only way to code, and
that objects and classes are inherent parts of everyone's universes.

If you were discussing the assembly language for bicycles, any
documentation could reasonably assume an understanding of frames,
wheels, pedals, and bell-cranks. Equally, any discussion of
object-oriented features can reasonably assume an understanding of
generic concepts like objects, classes, and inheritance, provided it
points out local weirdnesses. Repeating all the basics would make the
text cumbersome.

Perhaps the best approach would be a hyperlink to a generic
description (of which there are probably thousands already on the Web)
the first time a terms is introduced. The naive could follow it to
enligtenment, while the cognoscenti would not be distracted by it.


That would be an excellent way of doing it!

Loved the prose in your writing too!

Thank you!

I have been reading Perl5 tutorials on what classes
and objects are.  Since we do not have references
pointers, its is going to be fun.

Re: classes and objects questions

[Parrot Raiser]

Raku allows for several different programming paradigms; procedural,
functional, (as in languages like LISP), and object-oriented. It is
possible to write purely procedural Raku, while ignoring O-O features
completely, though it does take some dodging.

Object-oriented.programming first surfaced in the mid 1960s in
research projects, but was more generally visible by 1980. Like all
new programming concepts, it was going to cure cancer, bring about
world peace, and produce bug-free software. (And didn't, of course.)
It naturally had its specialised jargon, designed to ensure tribal
solidarity and repel infidels. It gradually spread with languages like
C++, (1979-83),  but remained a niche concept until Sun introduced
Java in 1995.

https://www.indeed.com/career-advice/career-development/what-is-object-oriented-programming

With the success of Java, later Javascript, and other new languages,
O-O and its jargon became
sufficiently mainstream that even many programmers working with other
languages learned the terminology. I suspect that many programmers
trained since the mid-90s assume that it's the only way to code, and
that objects and classes are inherent parts of everyone's universes.

If you were discussing the assembly language for bicycles, any
documentation could reasonably assume an understanding of frames,
wheels, pedals, and bell-cranks. Equally, any discussion of
object-oriented features can reasonably assume an understanding of
generic concepts like objects, classes, and inheritance, provided it
points out local weirdnesses. Repeating all the basics would make the
text cumbersome.

Perhaps the best approach would be a hyperlink to a generic
description (of which there are probably thousands already on the Web)
the first time a terms is introduced. The naive could follow it to
enligtenment, while the cognoscenti would not be distracted by it.

Re: classes and objects questions

[WFB]

JJ may be right about the OO thing, but it makes the
> tutorial pretty much useless.  How "class" and "object"
> *relate* to Raku needs to be explained.
>

When we are talking about describing Classes and Objects in a few words,
then I agree. Searching on the web reveals lots of tutorials for Java, C#
and so on with at least a few words about what classes and objects are.


>
> "The best is the enemy of the good".  It is better to
> slum it a bit and make the tutorial useful. JJ will
> hate it, but he will live.
>
I don't think JJ hates useful tutorials. But he has to find a balance. Look
in the Raku/doc repository
<https://github.com/Raku/doc/graphs/commit-activity>. Every week ~15
commits. And most of them on Sunday. Of course you can spend all day and
make the classtut perfect, at least what is your understanding of perfect.
But there is a lot more to be documented and maintained. You have to find a
level of detail that provides information for all readers and to have only
a limited amount of time and resources. That is JJ trying to do.
You are trying to shape the documentation for your needs. Sometimes the
best documentation is not your documentation.
In this case adding links for the Variables and a few sentences about
classes and objects would probably not hurt but I would listen to the
arguments JJ has. Because he knows the big pictures.

Best

>
> -T
>

Re: classes and objects questions

[ToddAndMargo via perl6-users]

For starters, I need to have the definition of
"class" and "object".  Then I need their rules.

-T




On 12/14/20 10:33 PM, WFB wrote:

Hi ToddAndMargo,

Thanks for the effort to improve the Raku docs. However, this is a Raku 
not OO (Object Oriented 
) related 
tutorial. As JJ already pointed out, these pages are to show the reader 
how you get things done in Raku, not what OO or other programming 
concepts are. There are probably thousands of OO books around and can 
teach you what a class is and why you need them. See the Wikipedia link 
I linked above for example. That's not in the scope of this tutorial.


The parts you are missing are already there, but unfortunately not 
linked. You can find them in the Raku documentation: => 
, $! 
 and $. 

:$ stands for a named parameter 
 
and can be also found in the documentation.
^$ is used for ranges and is also 
already there.


So the information you are missing is already there. You could argue 
that the links are missing and I would agree with you. But again this 
tutorial is for Raku classes not OO concept, Pairs, named parameters or 
ranges.


I hope that helped,
Wolfgang


Hi Wolfgang,

Thank you for the links!

JJ may be right about the OO thing, but it makes the
tutorial pretty much useless.  How "class" and "object"
*relate* to Raku needs to be explained.

"The best is the enemy of the good".  It is better to
slum it a bit and make the tutorial useful. JJ will
hate it, but he will live.

-T

Re: classes and objects questions

[WFB]

Hi ToddAndMargo,

Thanks for the effort to improve the Raku docs. However, this is a Raku not
OO (Object Oriented
) related
tutorial. As JJ already pointed out, these pages are to show the reader how
you get things done in Raku, not what OO or other programming concepts are.
There are probably thousands of OO books around and can teach you what a
class is and why you need them. See the Wikipedia link I linked above for
example. That's not in the scope of this tutorial.

The parts you are missing are already there, but unfortunately not linked.
You can find them in the Raku documentation:  =>
, $!
 and $.

:$ stands for a named parameter
 and
can be also found in the documentation.
^$ is used for ranges and is also already
there.

So the information you are missing is already there. You could argue that
the links are missing and I would agree with you. But again this tutorial
is for Raku classes not OO concept, Pairs, named parameters or ranges.

I hope that helped,
Wolfgang



On Tue, 15 Dec 2020 at 05:28, ToddAndMargo via perl6-users <
perl6-us...@perl.org> wrote:

> On 12/14/20 5:24 PM, Aureliano Guedes wrote:
> > That's why, as a community-developed language (including docs) I'd like
> > to suggest to you help to improve the docs.
> > This way, when I have - with some lucky - free time, I may learn with
> > you and all others that wrote these docs.
>
> Hi Aureliano,
>
> I absolutely adore Raku.  But the docs are truly awful.
> They do not start out simple and build to the complex.
> They throw terms out without defining them.  They use
> things in examples that are require advanced level of
> knowledge to understand, and so on and so forth.
> They have broken virtually rule of technical writing.
> The docs are simply refreshers for those that already
> know what they are doing and do not need them.
>
> I have tried several times to contribute to and get
> the docs improved.  I have been told I am providing
> too much detail or just get ignored.  So I have
> stopped.  The culture of the "docs" is not something
> I can change.
>
> I would absolute love to see some kind of contributed
> docs portal that any user could pick out a subject and
> write on it with the ability for others to correct
> mistakes or add content.
>
> Once I get Classes and Object figured out, I will
> write my own documentation of the subject.  If I
> think it is good enough to share (some of my technical
> writing stinks too), I will post it back here.
>
> For starters, I need to have the definition of
> "class" and "object".  Then I need their rules.
>
> -T
>

Re: classes and objects questions

[ToddAndMargo via perl6-users]

On 12/14/20 5:24 PM, Aureliano Guedes wrote:
That's why, as a community-developed language (including docs) I'd like 
to suggest to you help to improve the docs.
This way, when I have - with some lucky - free time, I may learn with 
you and all others that wrote these docs.


Hi Aureliano,

I absolutely adore Raku.  But the docs are truly awful.
They do not start out simple and build to the complex.
They throw terms out without defining them.  They use
things in examples that are require advanced level of
knowledge to understand, and so on and so forth.
They have broken virtually rule of technical writing.
The docs are simply refreshers for those that already
know what they are doing and do not need them.

I have tried several times to contribute to and get
the docs improved.  I have been told I am providing
too much detail or just get ignored.  So I have
stopped.  The culture of the "docs" is not something
I can change.

I would absolute love to see some kind of contributed
docs portal that any user could pick out a subject and
write on it with the ability for others to correct
mistakes or add content.

Once I get Classes and Object figured out, I will
write my own documentation of the subject.  If I
think it is good enough to share (some of my technical
writing stinks too), I will post it back here.

For starters, I need to have the definition of
"class" and "object".  Then I need their rules.

-T

Re: classes and objects questions

[Aureliano Guedes]

Hi Todd,

I'm a computational biologist and my knowledge is limited to what I need to
do data science and data analysis in my field.

So far, after a few years, I developed a very shy ability in programming
languages. Luckily, having Perl 5 as my first love.
Perhaps, at the time I was able to use Moose to support OO. Then I had to
do a job with Python and I didn't know the language itself at the time.
Perhaps, nowadays I have skills enough to Perl/Python/R also C/C++, but I
still missing skills in Raku, perhaps by the time or perhaps because I have
some language addiction.

But, as far I follow this group, trying to learn something, I saw you doing
some questions. And somehow I notice you have more knowledge than me in
this long waited new-born (after 15y) language.

That's why, as a community-developed language (including docs) I'd like to
suggest to you help to improve the docs.
This way, when I have - with some lucky - free time, I may learn with you
and all others that wrote these docs.

Regards,
acpguedes

PS: Perhaps, sorry for my really bad English

On Mon, Dec 14, 2020 at 7:34 PM ToddAndMargo via perl6-users <
perl6-us...@perl.org> wrote:

> Hi All,
>
> https://docs.raku.org/language/classtut
>
>   "A tutorial about creating and using classes
>   in Raku"
>
> So far so good.
>
>   "Raku has a rich built-in syntax for defining
>   and using classes."
>
> U. Forgot something did we?  What is a "class"?
>
>
> Next up:
>
>   "A default constructor allows the setting of
>   attributes for the created object:"
>
> U.  Forgot something else, did we?  What is
> an "object"?
>
>
> The "tutorial" leaves "class" and "object" up to
> the reader to guess at from what looks like an
> interesting example.
>
>
> But, again forgetting things, The tutorial also
> leaves the syntax up for guess work as well.  Not
> described are "$.", "$!", ":$", ^$" what are they
> and what are the rules for using them.
>
> Next up:
>
>   my $r = Rectangle.new(
>lower => Point.new(x => 0, y => 0),
>upper => Point.new(x => 10, y => 10));
>
>
> Why are we using ".new"?
>
> Why are we using the syntax for a hash (=>)?
>
> And:
>   $!upper.x
>
> What is the rules and purpose for such?  Why
> the "!" and why the "."?
>
>
> I do realize the documentation is not meant for
> beginners, but rather a refresher for advanced
> users that do not need it, but this link definitely
> said "tutorial" -- fifth word in.
>
> Would some kind soul please fill in the missing
> parts of the "tutorial" for me?
>
> Many thanks,
> -T
>


-- 
Aureliano Guedes
skype: aureliano.guedes
contato:  (11) 94292-6110
whatsapp +5511942926110

classes and objects questions

[ToddAndMargo via perl6-users]

Hi All,

https://docs.raku.org/language/classtut

 "A tutorial about creating and using classes
 in Raku"

So far so good.

 "Raku has a rich built-in syntax for defining
 and using classes."

U. Forgot something did we?  What is a "class"?


Next up:

 "A default constructor allows the setting of
 attributes for the created object:"

U.  Forgot something else, did we?  What is
an "object"?


The "tutorial" leaves "class" and "object" up to
the reader to guess at from what looks like an
interesting example.


But, again forgetting things, The tutorial also
leaves the syntax up for guess work as well.  Not
described are "$.", "$!", ":$", ^$" what are they
and what are the rules for using them.

Next up:

 my $r = Rectangle.new(
  lower => Point.new(x => 0, y => 0),
  upper => Point.new(x => 10, y => 10));


Why are we using ".new"?

Why are we using the syntax for a hash (=>)?

And:
 $!upper.x

What is the rules and purpose for such?  Why
the "!" and why the "."?


I do realize the documentation is not meant for
beginners, but rather a refresher for advanced
users that do not need it, but this link definitely
said "tutorial" -- fifth word in.

Would some kind soul please fill in the missing
parts of the "tutorial" for me?

Many thanks,
-T

Re: regex objects as hash keys

[Joseph Brenner]

> Object hashes currently come with a performance penalty.  That's why they are 
> currently not the default.

Thanks, that makes sense.


On 4/6/20, Elizabeth Mattijsen  wrote:
>> On 6 Apr 2020, at 07:19, Joseph Brenner  wrote:
>>> If you want a Hash which allows any
>> kind of object as key, you have to declare it such:
>>
>>>  my $obj = Rutabaga.new;
>>> my %vegeout{Any};  # <-- see:
>>> https://docs.raku.org/language/hashmap#Non-string_keys_(object_hash)
>>
>> That's an interesting detail, I didn't get that that behavior wasn't
>> the default.
>
> Object hashes currently come with a performance penalty.  That's why they
> are currently not the default.

Re: regex objects as hash keys

[Elizabeth Mattijsen]

> On 6 Apr 2020, at 07:19, Joseph Brenner  wrote:
>> If you want a Hash which allows any
> kind of object as key, you have to declare it such:
> 
>>  my $obj = Rutabaga.new;
>> my %vegeout{Any};  # <-- see: 
>> https://docs.raku.org/language/hashmap#Non-string_keys_(object_hash)
> 
> That's an interesting detail, I didn't get that that behavior wasn't
> the default.

Object hashes currently come with a performance penalty.  That's why they are 
currently not the default.

Re: regex objects as hash keys

[Joseph Brenner]

> If you want a Hash which allows any
kind of object as key, you have to declare it such:

>   my $obj = Rutabaga.new;
>  my %vegeout{Any};  # <-- see: 
> https://docs.raku.org/language/hashmap#Non-string_keys_(object_hash)

That's an interesting detail, I didn't get that that behavior wasn't
the default.  Thanks much.



On 4/5/20, Tobias Boege  wrote:
> On Sun, 05 Apr 2020, Joseph Brenner wrote:
>> I find in Raku that (as expected) I can use an object as a hash key:
>>
>> class Rutabaga { method color { say "purple (and white)"; } }
>>
>> my $obj = Rutabaga.new
>> my %vegeout;
>> %vegeout{ $obj } = "this works";
>>
>> And for something I was doing I wanted to save up
>> data about matches for various different regexs,
>> so I thought I could just use a hash for this, like so:
>>
>> my (%match_locs, $loc);
>>
>> my $godzilla_rx  = rx:i{ << godzilla >> };
>> if $text ~~ m/$godzilla_rx/ {
>> $loc = $/.from;
>> say "Godzilla: Found at $loc!";
>> %match_locs{ $godzilla_rx } = $loc;
>> }
>>
>> But using a regex object as a hash key evidently doesn't work,
>> it gives you the warning message:
>>
>>#  Regex object coerced to string (please use .gist or .perl to do
>> that)
>>
>> And what's worse is it coerces to an *empty list* which means *every*
>> regex is treated as the same key.
>>
>> If you I follow the advice to use the *.perl, then that works, of course:
>>
>> %match_locs{ $godzilla_rx.perl } = $loc;
>>
>> But you wouldn't be able to use the keys of the hash as a regex
>> object later, which seems sub-optimal, though not a concern for
>> my present purposes.
>
> The same thing happened with your Rutabaga object. It had a default
> Str method that was called when you used it as a hash key. It didn't
> really store the object in the key but just its .Str:
>
>   %vegeout.keys.any ~~ Rutabaga;  # OUTPUT: «False»
>   %vegeout.keys.all ~~ Str;   # OUTPUT: «True»
>   %vegeout.keys[0] === $obj;  # OUTPUT: «False»
>
> This is because Hash objects, by default, have Str(Any) keys, meaning
> Str and coercing when required. If you want a Hash which allows any
> kind of object as key, you have to declare it such:
>
>   my $obj = Rutabaga.new;
>   my %vegeout{Any};  # <-- see:
> https://docs.raku.org/language/hashmap#Non-string_keys_(object_hash)
>   %vegeout{$obj} = "this works";
>   %vegeout.keys.all ~~ Rutabaga;  # OUTPUT: «True»
>   %vegeout.keys[0] === $obj;  # OUTPUT: «True»
>
> This will also work with Regex objects.
>
> Regards,
> Tobias
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>

Re: regex objects as hash keys

[Tobias Boege]

On Sun, 05 Apr 2020, Joseph Brenner wrote:
> I find in Raku that (as expected) I can use an object as a hash key:
> 
> class Rutabaga { method color { say "purple (and white)"; } }
> 
> my $obj = Rutabaga.new
> my %vegeout;
> %vegeout{ $obj } = "this works";
> 
> And for something I was doing I wanted to save up
> data about matches for various different regexs,
> so I thought I could just use a hash for this, like so:
> 
> my (%match_locs, $loc);
> 
> my $godzilla_rx  = rx:i{ << godzilla >> };
> if $text ~~ m/$godzilla_rx/ {
> $loc = $/.from;
> say "Godzilla: Found at $loc!";
> %match_locs{ $godzilla_rx } = $loc;
> }
> 
> But using a regex object as a hash key evidently doesn't work,
> it gives you the warning message:
> 
>#  Regex object coerced to string (please use .gist or .perl to do that)
> 
> And what's worse is it coerces to an *empty list* which means *every*
> regex is treated as the same key.
> 
> If you I follow the advice to use the *.perl, then that works, of course:
> 
> %match_locs{ $godzilla_rx.perl } = $loc;
> 
> But you wouldn't be able to use the keys of the hash as a regex
> object later, which seems sub-optimal, though not a concern for
> my present purposes.

The same thing happened with your Rutabaga object. It had a default
Str method that was called when you used it as a hash key. It didn't
really store the object in the key but just its .Str:

  %vegeout.keys.any ~~ Rutabaga;  # OUTPUT: «False»
  %vegeout.keys.all ~~ Str;   # OUTPUT: «True»
  %vegeout.keys[0] === $obj;  # OUTPUT: «False»

This is because Hash objects, by default, have Str(Any) keys, meaning
Str and coercing when required. If you want a Hash which allows any
kind of object as key, you have to declare it such:

  my $obj = Rutabaga.new;
  my %vegeout{Any};  # <-- see: 
https://docs.raku.org/language/hashmap#Non-string_keys_(object_hash)
  %vegeout{$obj} = "this works";
  %vegeout.keys.all ~~ Rutabaga;  # OUTPUT: «True»
  %vegeout.keys[0] === $obj;  # OUTPUT: «True»

This will also work with Regex objects.

Regards,
Tobias

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

regex objects as hash keys

[Joseph Brenner]

I find in Raku that (as expected) I can use an object as a hash key:

class Rutabaga { method color { say "purple (and white)"; } }

my $obj = Rutabaga.new
my %vegeout;
%vegeout{ $obj } = "this works";

And for something I was doing I wanted to save up
data about matches for various different regexs,
so I thought I could just use a hash for this, like so:

my (%match_locs, $loc);

my $godzilla_rx  = rx:i{ << godzilla >> };
if $text ~~ m/$godzilla_rx/ {
$loc = $/.from;
say "Godzilla: Found at $loc!";
%match_locs{ $godzilla_rx } = $loc;
}

But using a regex object as a hash key evidently doesn't work,
it gives you the warning message:

   #  Regex object coerced to string (please use .gist or .perl to do that)

And what's worse is it coerces to an *empty list* which means *every*
regex is treated as the same key.

If you I follow the advice to use the *.perl, then that works, of course:

%match_locs{ $godzilla_rx.perl } = $loc;

But you wouldn't be able to use the keys of the hash as a regex
object later, which seems sub-optimal, though not a concern for
my present purposes.

Re: getting comb to return match objects

[Joseph Brenner]

Oh, you know, think I've spotted a source of confusion in this
thread... Liz-- I think my accident-- replied to me directly, and we
kept going talking about this without cc-ing the list.  So yeah, I
pointed out there was a bug with the routine form of comb that wasn't
in the Str method, and she ran off and fixed it immediately.




On 11/16/19, Elizabeth Mattijsen  wrote:
> I think
> https://github.com/rakudo/rakudo/commit/dd2f072d6aae04bfcf2603c6bdcd2f2e7d804ea8
> fixed it.
>
>> On 16 Nov 2019, at 18:57, Timo Paulssen  wrote:
>>
>> Oh dang!
>>
>> This may very well be a rakudobug. I've actually never used the sub form
>> of comb, only ever the method form, for which the "match" named
>> parameter definitely exists:
>>
>> "a;b;c".comb(/\w/, match => True);
>> (｢a｣ ｢b｣ ｢c｣)
>>
>> Someone will have to fix that and then the code from my mail will
>> retroactively become correct ;)
>>
>> HTH
>>   - Timo
>>
>> On 16/11/2019 18:35, William Michels wrote:
>>> Hello Timo, and thank you for taking the time to explain how "comb"
>>> routine signatures work. I have no doubt your description is the
>>> correct way to use comb routine(s) in Raku/Perl6.
>>>
>>> First of all, I should preface my remarks by saying that I'm using
>>> Rakudo (moar) 2019.07.1, with the Linenoise module to run the
>>> Raku/Perl6 REPL. It has been suggested to me that my install might
>>> somehow be broken, because I tried to 'roll-my-own' Rakudo-Star
>>> release (basically I copied over pre-installed modules from my Rakudo
>>> 2019.03 install, and ran 'zef update').
>>>
>>> In any case, I haven't been able to get the code you posted to work. I
>>> checked all six examples in the REPL, and the last example I checked
>>> at the command line as well. I'm hoping someone on the list running
>>> Rakudo (moar) 2019.07.1 can confirm/refute my results:
>>>
>>>> #Timo
>>> Nil
>>>> comb(/\w/, "a;b;c", match => True);
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> comb(/\w/, "a;b;c", :match);
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> comb(/\w/, "a;b;c", :match(True));
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> comb(/\w/, "a;b;c", :!match);
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> comb(/\w/, "a;b;c", :match(False));
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> comb(/\w/, "a;b;c", 2, :match);
>>> Unexpected named argument 'match' passed
>>>  in block  at  line 1
>>>
>>>> $*VM
>>> moar (2019.07.1)
>>>> exit
>>> mbook:~ homedir$ perl6 -e 'comb(/\w/, "a;b;c", 2, :match);'
>>> Unexpected named argument 'match' passed
>>>  in block  at -e line 1
>>> mbook:~ homedir$
>>>
>>> As for what's going on, I'm wondering if there might be an issue with
>>> "comb" signatures in general. There exists both a '(Str) routine comb'
>>> and a '(Cool) routine comb'. Maybe these two routines are somehow
>>> interfering with each other?
>>>
>>> Thank you, and any further help appreciated, Bill.
>>>
>>>
>>> On Sat, Nov 16, 2019 at 6:34 AM Timo Paulssen  wrote:
>>>> Hi Bill,
>>>>
>>>> In your repl examples you're actually passing the True or False as a
>>>> positional parameter, which makes it go into the slot for $limit, not
>>>> the slot for :$match.
>>>>
>>>> In order to pass true or false for the "match" named parameter you have
>>>> different syntactical options:
>>>>
>>>>  comb(/\w/, "a;b;c", match => True) # maybe the simplest is using a
>>>> pair
>>>>
>>>>  comb(/\w/, "a;b;c", :match) # using "colon pair" syntax; it's syntax
>>>> that puts a colon at the beginning and makes a pair
>>>>
>>>>  comb(/\w/, "a;b;c", :match(True)) # :match is short for match => True,
>>>> and :match(True) is long for match => True
>>>>
>>>>  comb(/\w/, "a;b;c", :!match) # putting a ! after the : negates the
>>>> pair, i.e. it's now matc

Re: getting comb to return match objects

[Parrot Raiser]

What do the official tests for this show?

On 11/16/19, Joseph Brenner  wrote:
> William Michelswrote:
>
>> I went over this with Joe as well, and I was
>> equally confused.
>
> Part of our trouble was we were playing around with the
> routine form of comb (rather than the Str method), which
> had a bug in it with the :match option (which lizmat just fixed).
> Even when we tried the Right Thing it was still going wrong.
>
> But then, like I was saying at the time, I really needed to
> re-read the material on subroutine signatures-- I wasn't
> even sure if the ":match" flag was supposed to be positional
> or not-- a point Yary picked up on.
>
>> So if I understand what you're
>> saying correctly, if we see something like "Bool
>> :$match" that says we should drop the dollar-sign
>> ($) and enter ":match" to set "Bool" = True, and
>> thus return the list of match objects?
>
> Something like that.  The ":$match" declares a variable named
> $match for use inside the routine-- it also makes it a little
> simpler to work with an input variable also named $match.
>
> Take this as an example:
>
> sub doom_flag (Bool :$flag) {
> if $flag {  # declared by the sub signature, no "my $flag"
> say "The flag is UP"
> } else {
> say "The flag is down."
> }
> }
>
> doom_flag();  # The flag is down.
>
> # All of the following invocations say:
> #   The flag is UP
>
> doom_flag( flag => True );
> doom_flag( :flag );
>
> my $flag = True;
> doom_flag( flag => $flag );
> doom_flag( :$flag );
>
> That last one is a funny short-cut for entering a Pair that's built-in
> to Raku: it's pretty common when you're working with named arguments to
> end up with code that looks redundant, like this:
>
>make_connection(
> ip =>  $ip,
> user =>  $user,
> pw   =>  $pw
> );
>
> But you could just use "colon-pair"s and do it like this:
>
>make_connection( :$ip, :$user, :$pw );
>
> Does this make more sense?  There's a few different idiomatic short-cuts
> here that I think are supposed to seem similar and suggest each other...
>
>
> On 11/16/19, William Michels  wrote:
>> Hi Yary,
>>
>> I went over this with Joe as well, and I was equally confused. So if I
>> understand what you're saying correctly, if we see something like
>> "Bool :$match" that says we should drop the dollar-sign ($) and enter
>> ":match" to set "Bool" = True, and thus return the list of match
>> objects?
>>
>> On another note (or possibly the same note), I tried code similar to
>> Joe's with fair success. I was able to get the REPL to understand a
>> "True" or "False" parameter, but never in conjunction with a "$limit"
>> parameter. Is this the correct behaviour, and why?
>>
>>> #REPL
>> Nil
>>> say comb(/\w/, "a;b;c",  False).perl;
>> ().Seq
>>> say comb(/\w/, "a;b;c",  True).perl;
>> ("a",).Seq
>>> say comb(/\w+/, "a;b;c",  True).perl;
>> ("a",).Seq
>>> say comb(/\w+/, "a;b;c",  2).perl;
>> ("a", "b").Seq
>>> say comb(/\w+/, "a;b;c",  3).perl;
>> ("a", "b", "c").Seq
>>> say comb(/\w+/, "a;b;c",  4).perl;
>> ("a", "b", "c").Seq
>>> say comb(/\w+/, "a;b;c",  True).perl;
>> ("a",).Seq
>>> say comb(/\w+/, "a;b;c",  2, True).perl;
>> Too many positionals passed; expected 2 or 3 arguments but got 4
>>   in block  at  line 1
>>
>>> say comb(/\w+/, "a;b;c",  2, :True).perl;
>> Unexpected named argument 'True' passed
>>   in block  at  line 1
>>
>>> $*VM
>> moar (2019.07.1)
>>
>> Any help appreciated, Bill.
>>
>>
>>
>>
>> On Mon, Nov 11, 2019 at 9:46 AM yary  wrote:
>>>
>>> The syntax is in the declaration you pasted in your email
>>>
>>> > multi sub    comb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
>>> > :$match)
>>>
>>> The colon in "Bool :$match" makes it a named argument. Not sure where
>>> definitive docs are, decent starting point is
>>> https://docs.perl6.org/type/Signature#Positional_vs._named_arguments
>>&g

Re: getting comb to return match objects

[Joseph Brenner]

William Michels  wrote:

> I went over this with Joe as well, and I was
> equally confused.

Part of our trouble was we were playing around with the
routine form of comb (rather than the Str method), which
had a bug in it with the :match option (which lizmat just fixed).
Even when we tried the Right Thing it was still going wrong.

But then, like I was saying at the time, I really needed to
re-read the material on subroutine signatures-- I wasn't
even sure if the ":match" flag was supposed to be positional
or not-- a point Yary picked up on.

> So if I understand what you're
> saying correctly, if we see something like "Bool
> :$match" that says we should drop the dollar-sign
> ($) and enter ":match" to set "Bool" = True, and
> thus return the list of match objects?

Something like that.  The ":$match" declares a variable named
$match for use inside the routine-- it also makes it a little
simpler to work with an input variable also named $match.

Take this as an example:

sub doom_flag (Bool :$flag) {
if $flag {  # declared by the sub signature, no "my $flag"
say "The flag is UP"
} else {
say "The flag is down."
}
}

doom_flag();  # The flag is down.

# All of the following invocations say:
#   The flag is UP

doom_flag( flag => True );
doom_flag( :flag );

my $flag = True;
doom_flag( flag => $flag );
doom_flag( :$flag );

That last one is a funny short-cut for entering a Pair that's built-in
to Raku: it's pretty common when you're working with named arguments to
end up with code that looks redundant, like this:

   make_connection(
ip =>  $ip,
user =>  $user,
pw   =>  $pw
);

But you could just use "colon-pair"s and do it like this:

   make_connection( :$ip, :$user, :$pw );

Does this make more sense?  There's a few different idiomatic short-cuts
here that I think are supposed to seem similar and suggest each other...


On 11/16/19, William Michels  wrote:
> Hi Yary,
>
> I went over this with Joe as well, and I was equally confused. So if I
> understand what you're saying correctly, if we see something like
> "Bool :$match" that says we should drop the dollar-sign ($) and enter
> ":match" to set "Bool" = True, and thus return the list of match
> objects?
>
> On another note (or possibly the same note), I tried code similar to
> Joe's with fair success. I was able to get the REPL to understand a
> "True" or "False" parameter, but never in conjunction with a "$limit"
> parameter. Is this the correct behaviour, and why?
>
>> #REPL
> Nil
>> say comb(/\w/, "a;b;c",  False).perl;
> ().Seq
>> say comb(/\w/, "a;b;c",  True).perl;
> ("a",).Seq
>> say comb(/\w+/, "a;b;c",  True).perl;
> ("a",).Seq
>> say comb(/\w+/, "a;b;c",  2).perl;
> ("a", "b").Seq
>> say comb(/\w+/, "a;b;c",  3).perl;
> ("a", "b", "c").Seq
>> say comb(/\w+/, "a;b;c",  4).perl;
> ("a", "b", "c").Seq
>> say comb(/\w+/, "a;b;c",  True).perl;
> ("a",).Seq
>> say comb(/\w+/, "a;b;c",  2, True).perl;
> Too many positionals passed; expected 2 or 3 arguments but got 4
>   in block  at  line 1
>
>> say comb(/\w+/, "a;b;c",  2, :True).perl;
> Unexpected named argument 'True' passed
>   in block  at  line 1
>
>> $*VM
> moar (2019.07.1)
>
> Any help appreciated, Bill.
>
>
>
>
> On Mon, Nov 11, 2019 at 9:46 AM yary  wrote:
>>
>> The syntax is in the declaration you pasted in your email
>>
>> > multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
>> > :$match)
>>
>> The colon in "Bool :$match" makes it a named argument. Not sure where
>> definitive docs are, decent starting point is
>> https://docs.perl6.org/type/Signature#Positional_vs._named_arguments
>>
>>
>> -y
>>
>>
>> On Sun, Nov 10, 2019 at 11:18 PM Joseph Brenner 
>> wrote:
>>>
>>> Thanks, that form does what I want--
>>>
>>> I don't see how I could've understood that from the docs, though.
>>> For example, I don't see any place where the :match adverb is
>>> mentioned for either the method or routine form of comb.
>>>
>>>
>>>
>>> On 11/10/19, Elizabeth Mattijsen  wrote:
>>> > dd "foobar".comb(/./, :g, :match);
>>> > (｢f｣ ｢o｣ ｢o｣ ｢b｣ ｢a｣ ｢r｣)
>>> >
>>> >> On 10 Nov 2019, at 23:46, Joseph Brenner  wrote:
>>> >>
>>> >> Can someone give me an example of how to use the comb routine to
>>> >> return a list of match objects?
>>> >>
>>> >> The documentation here:
>>> >>
>>> >> https://docs.perl6.org/type/Str#routine_comb
>>> >>
>>> >> Mentions a boolean option to get match objects:
>>> >>
>>> >>> If $matcher is a Regex, each Match object is
>>> >>> converted to a Str, unless $match is set.
>>> >>
>>> >> I gather that I must be reading this signature
>>> >> wrong somehow, I can't get it to work:
>>> >>
>>> >>> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
>>> >>> :$match)
>>> >>
>>> >> I keep trying variations of things like this:
>>> >>
>>> >>my @hits = comb(m/$search_pattern/, $chunk, 100, True);
>>> >
>

Re: getting comb to return match objects

[Elizabeth Mattijsen]

I think 
https://github.com/rakudo/rakudo/commit/dd2f072d6aae04bfcf2603c6bdcd2f2e7d804ea8
 fixed it.

> On 16 Nov 2019, at 18:57, Timo Paulssen  wrote:
> 
> Oh dang!
> 
> This may very well be a rakudobug. I've actually never used the sub form
> of comb, only ever the method form, for which the "match" named
> parameter definitely exists:
> 
> "a;b;c".comb(/\w/, match => True);
> (｢a｣ ｢b｣ ｢c｣)
> 
> Someone will have to fix that and then the code from my mail will
> retroactively become correct ;)
> 
> HTH
>   - Timo
> 
> On 16/11/2019 18:35, William Michels wrote:
>> Hello Timo, and thank you for taking the time to explain how "comb"
>> routine signatures work. I have no doubt your description is the
>> correct way to use comb routine(s) in Raku/Perl6.
>> 
>> First of all, I should preface my remarks by saying that I'm using
>> Rakudo (moar) 2019.07.1, with the Linenoise module to run the
>> Raku/Perl6 REPL. It has been suggested to me that my install might
>> somehow be broken, because I tried to 'roll-my-own' Rakudo-Star
>> release (basically I copied over pre-installed modules from my Rakudo
>> 2019.03 install, and ran 'zef update').
>> 
>> In any case, I haven't been able to get the code you posted to work. I
>> checked all six examples in the REPL, and the last example I checked
>> at the command line as well. I'm hoping someone on the list running
>> Rakudo (moar) 2019.07.1 can confirm/refute my results:
>> 
>>> #Timo
>> Nil
>>> comb(/\w/, "a;b;c", match => True);
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> comb(/\w/, "a;b;c", :match);
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> comb(/\w/, "a;b;c", :match(True));
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> comb(/\w/, "a;b;c", :!match);
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> comb(/\w/, "a;b;c", :match(False));
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> comb(/\w/, "a;b;c", 2, :match);
>> Unexpected named argument 'match' passed
>>  in block  at  line 1
>> 
>>> $*VM
>> moar (2019.07.1)
>>> exit
>> mbook:~ homedir$ perl6 -e 'comb(/\w/, "a;b;c", 2, :match);'
>> Unexpected named argument 'match' passed
>>  in block  at -e line 1
>> mbook:~ homedir$
>> 
>> As for what's going on, I'm wondering if there might be an issue with
>> "comb" signatures in general. There exists both a '(Str) routine comb'
>> and a '(Cool) routine comb'. Maybe these two routines are somehow
>> interfering with each other?
>> 
>> Thank you, and any further help appreciated, Bill.
>> 
>> 
>> On Sat, Nov 16, 2019 at 6:34 AM Timo Paulssen  wrote:
>>> Hi Bill,
>>> 
>>> In your repl examples you're actually passing the True or False as a 
>>> positional parameter, which makes it go into the slot for $limit, not the 
>>> slot for :$match.
>>> 
>>> In order to pass true or false for the "match" named parameter you have 
>>> different syntactical options:
>>> 
>>>  comb(/\w/, "a;b;c", match => True) # maybe the simplest is using a pair
>>> 
>>>  comb(/\w/, "a;b;c", :match) # using "colon pair" syntax; it's syntax that 
>>> puts a colon at the beginning and makes a pair
>>> 
>>>  comb(/\w/, "a;b;c", :match(True)) # :match is short for match => True, and 
>>> :match(True) is long for match => True
>>> 
>>>  comb(/\w/, "a;b;c", :!match) # putting a ! after the : negates the pair, 
>>> i.e. it's now match => False
>>> 
>>>  comb(/\w/, "a;b;c", :match(False)) # same value
>>> 
>>> And on top of that, you can add the third positional parameter to pass a 
>>> value for $limit
>>> 
>>>  comb(/\w/, "a;b;c", 2, :match) # output up to two results, as match objects
>>> 
>>> Here's a few comments on the examples you pasted:
>>> 
>>> 
>>>> On another note (or possibly the same note), I tried code similar to > 
>>>> Joe's with fair success. I was able to get the REPL to understand a > 
>>>> "True" or "False" parameter, but never in conjunction with a > "$limit" 
>

Re: getting comb to return match objects

[Timo Paulssen]

Oh dang!

This may very well be a rakudobug. I've actually never used the sub form
of comb, only ever the method form, for which the "match" named
parameter definitely exists:

"a;b;c".comb(/\w/, match => True);
(｢a｣ ｢b｣ ｢c｣)

Someone will have to fix that and then the code from my mail will
retroactively become correct ;)

HTH
  - Timo

On 16/11/2019 18:35, William Michels wrote:
> Hello Timo, and thank you for taking the time to explain how "comb"
> routine signatures work. I have no doubt your description is the
> correct way to use comb routine(s) in Raku/Perl6.
>
> First of all, I should preface my remarks by saying that I'm using
> Rakudo (moar) 2019.07.1, with the Linenoise module to run the
> Raku/Perl6 REPL. It has been suggested to me that my install might
> somehow be broken, because I tried to 'roll-my-own' Rakudo-Star
> release (basically I copied over pre-installed modules from my Rakudo
> 2019.03 install, and ran 'zef update').
>
> In any case, I haven't been able to get the code you posted to work. I
> checked all six examples in the REPL, and the last example I checked
> at the command line as well. I'm hoping someone on the list running
> Rakudo (moar) 2019.07.1 can confirm/refute my results:
>
>> #Timo
> Nil
>> comb(/\w/, "a;b;c", match => True);
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> comb(/\w/, "a;b;c", :match);
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> comb(/\w/, "a;b;c", :match(True));
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> comb(/\w/, "a;b;c", :!match);
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> comb(/\w/, "a;b;c", :match(False));
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> comb(/\w/, "a;b;c", 2, :match);
> Unexpected named argument 'match' passed
>   in block  at  line 1
>
>> $*VM
> moar (2019.07.1)
>> exit
> mbook:~ homedir$ perl6 -e 'comb(/\w/, "a;b;c", 2, :match);'
> Unexpected named argument 'match' passed
>   in block  at -e line 1
> mbook:~ homedir$
>
> As for what's going on, I'm wondering if there might be an issue with
> "comb" signatures in general. There exists both a '(Str) routine comb'
> and a '(Cool) routine comb'. Maybe these two routines are somehow
> interfering with each other?
>
> Thank you, and any further help appreciated, Bill.
>
>
> On Sat, Nov 16, 2019 at 6:34 AM Timo Paulssen  wrote:
>> Hi Bill,
>>
>> In your repl examples you're actually passing the True or False as a 
>> positional parameter, which makes it go into the slot for $limit, not the 
>> slot for :$match.
>>
>> In order to pass true or false for the "match" named parameter you have 
>> different syntactical options:
>>
>>   comb(/\w/, "a;b;c", match => True) # maybe the simplest is using a pair
>>
>>   comb(/\w/, "a;b;c", :match) # using "colon pair" syntax; it's syntax that 
>> puts a colon at the beginning and makes a pair
>>
>>   comb(/\w/, "a;b;c", :match(True)) # :match is short for match => True, and 
>> :match(True) is long for match => True
>>
>>   comb(/\w/, "a;b;c", :!match) # putting a ! after the : negates the pair, 
>> i.e. it's now match => False
>>
>>   comb(/\w/, "a;b;c", :match(False)) # same value
>>
>> And on top of that, you can add the third positional parameter to pass a 
>> value for $limit
>>
>>   comb(/\w/, "a;b;c", 2, :match) # output up to two results, as match objects
>>
>> Here's a few comments on the examples you pasted:
>>
>>
>>> On another note (or possibly the same note), I tried code similar to > 
>>> Joe's with fair success. I was able to get the REPL to understand a > 
>>> "True" or "False" parameter, but never in conjunction with a > "$limit" 
>>> parameter. Is this the correct behaviour, and why?
>> The surprise here comes from Bool actually being derived from Int, and 
>> therefore being totally acceptable values to pass for $limit.
>>>> #REPL > Nil >> say comb(/\w/, "a;b;c", False).perl; > ().Seq You can see 
>>>> here that it gave no results; that's because it interpreted the False as 0 
>>>> in the $limit parameter.
>>>> say comb(/\w/, "a;b;c", True).perl; > ("a",).Seq
>> Here the True is interpreted as 1 for $limit, giving you

Re: getting comb to return match objects

[William Michels via perl6-users]

Hello Timo, and thank you for taking the time to explain how "comb"
routine signatures work. I have no doubt your description is the
correct way to use comb routine(s) in Raku/Perl6.

First of all, I should preface my remarks by saying that I'm using
Rakudo (moar) 2019.07.1, with the Linenoise module to run the
Raku/Perl6 REPL. It has been suggested to me that my install might
somehow be broken, because I tried to 'roll-my-own' Rakudo-Star
release (basically I copied over pre-installed modules from my Rakudo
2019.03 install, and ran 'zef update').

In any case, I haven't been able to get the code you posted to work. I
checked all six examples in the REPL, and the last example I checked
at the command line as well. I'm hoping someone on the list running
Rakudo (moar) 2019.07.1 can confirm/refute my results:

> #Timo
Nil
> comb(/\w/, "a;b;c", match => True);
Unexpected named argument 'match' passed
  in block  at  line 1

> comb(/\w/, "a;b;c", :match);
Unexpected named argument 'match' passed
  in block  at  line 1

> comb(/\w/, "a;b;c", :match(True));
Unexpected named argument 'match' passed
  in block  at  line 1

> comb(/\w/, "a;b;c", :!match);
Unexpected named argument 'match' passed
  in block  at  line 1

> comb(/\w/, "a;b;c", :match(False));
Unexpected named argument 'match' passed
  in block  at  line 1

> comb(/\w/, "a;b;c", 2, :match);
Unexpected named argument 'match' passed
  in block  at  line 1

> $*VM
moar (2019.07.1)
>
> exit
mbook:~ homedir$ perl6 -e 'comb(/\w/, "a;b;c", 2, :match);'
Unexpected named argument 'match' passed
  in block  at -e line 1
mbook:~ homedir$

As for what's going on, I'm wondering if there might be an issue with
"comb" signatures in general. There exists both a '(Str) routine comb'
and a '(Cool) routine comb'. Maybe these two routines are somehow
interfering with each other?

Thank you, and any further help appreciated, Bill.


On Sat, Nov 16, 2019 at 6:34 AM Timo Paulssen  wrote:
>
> Hi Bill,
>
> In your repl examples you're actually passing the True or False as a 
> positional parameter, which makes it go into the slot for $limit, not the 
> slot for :$match.
>
> In order to pass true or false for the "match" named parameter you have 
> different syntactical options:
>
>   comb(/\w/, "a;b;c", match => True) # maybe the simplest is using a pair
>
>   comb(/\w/, "a;b;c", :match) # using "colon pair" syntax; it's syntax that 
> puts a colon at the beginning and makes a pair
>
>   comb(/\w/, "a;b;c", :match(True)) # :match is short for match => True, and 
> :match(True) is long for match => True
>
>   comb(/\w/, "a;b;c", :!match) # putting a ! after the : negates the pair, 
> i.e. it's now match => False
>
>   comb(/\w/, "a;b;c", :match(False)) # same value
>
> And on top of that, you can add the third positional parameter to pass a 
> value for $limit
>
>   comb(/\w/, "a;b;c", 2, :match) # output up to two results, as match objects
>
> Here's a few comments on the examples you pasted:
>
>
> > On another note (or possibly the same note), I tried code similar to > 
> > Joe's with fair success. I was able to get the REPL to understand a > 
> > "True" or "False" parameter, but never in conjunction with a > "$limit" 
> > parameter. Is this the correct behaviour, and why?
> The surprise here comes from Bool actually being derived from Int, and 
> therefore being totally acceptable values to pass for $limit.
> >> #REPL > Nil >> say comb(/\w/, "a;b;c", False).perl; > ().Seq You can see 
> >> here that it gave no results; that's because it interpreted the False as 0 
> >> in the $limit parameter.
>
> >> say comb(/\w/, "a;b;c", True).perl; > ("a",).Seq
> Here the True is interpreted as 1 for $limit, giving you just "a", and it's a 
> string because the match named parameter wasn't given and defaulted to False.
> >> say comb(/\w+/, "a;b;c", True).perl; > ("a",).Seq
> The difference between \w and \w+ isn't noticeable here, as the source string 
> only ever has single word character in a row, but you can try with "ab;cd;ef" 
> for example with both \w and \w+.
>
> >> say comb(/\w+/, "a;b;c", 2).perl; > ("a", "b").Seq >> say comb(/\w+/, 
> >> "a;b;c", 3).perl; > ("a", "b", "c").Seq >> say comb(/\w+/, "a;b;c", 
> >> 4).perl; > ("a", "b", "c").Seq >> say comb(/\w+/, "a;b;c", True).perl; > 
> >> ("a",).Seq
> Same as above; True being interpreted as 1
>
> >> say comb(/\w+/, "a;b;c", 2, True).perl; > Too many positionals passed; 
> >> expected 2 or 3 arguments but got 4 in > block  at  
> >> line 1
> There's no syntax here that distinguishes 2, a positional parameter, from 
> True, also a positional parameter.
>
> >> say comb(/\w+/, "a;b;c", 2, :True).perl; > Unexpected named argument 
> >> 'True' passed in block  at  file> line 1
> The issue here is that :True is short for True => True, i.e. passing the 
> value True to the named parameter called "True", easy to get confused by the 
> error message here!
> > Any help appreciated, Bill.
>
> I hope the explanations make sense!
>   - Timo

Re: getting comb to return match objects

[Timo Paulssen]

Hi Bill,

In your repl examples you're actually passing the True or False as a
positional parameter, which makes it go into the slot for $limit, not
the slot for :$match.

In order to pass true or false for the "match" named parameter you have
different syntactical options:

  comb(/\w/, "a;b;c", match => True) # maybe the simplest is using a pair

  comb(/\w/, "a;b;c", :match) # using "colon pair" syntax; it's syntax
that puts a colon at the beginning and makes a pair

  comb(/\w/, "a;b;c", :match(True)) # :match is short for match => True,
and :match(True) is long for match => True

  comb(/\w/, "a;b;c", :!match) # putting a ! after the : negates the
pair, i.e. it's now match => False

  comb(/\w/, "a;b;c", :match(False)) # same value

And on top of that, you can add the third positional parameter to pass a
value for $limit

  comb(/\w/, "a;b;c", 2, :match) # output up to two results, as match
objects

Here's a few comments on the examples you pasted:


> On another note (or possibly the same note), I tried code similar to > Joe's 
> with fair success. I was able to get the REPL to understand a >
"True" or "False" parameter, but never in conjunction with a > "$limit"
parameter. Is this the correct behaviour, and why?
The surprise here comes from Bool actually being derived from Int, and
therefore being totally acceptable values to pass for $limit.
>> #REPL > Nil >> say comb(/\w/, "a;b;c", False).perl; > ().Seq You can see here
that it gave no results; that's because it interpreted the False as 0 in
the $limit parameter.

>> say comb(/\w/, "a;b;c",  True).perl; > ("a",).Seq
Here the True is interpreted as 1 for $limit, giving you just "a", and
it's a string because the match named parameter wasn't given and
defaulted to False.
>> say comb(/\w+/, "a;b;c",  True).perl; > ("a",).Seq
The difference between \w and \w+ isn't noticeable here, as the source
string only ever has single word character in a row, but you can try
with "ab;cd;ef" for example with both \w and \w+.

>> say comb(/\w+/, "a;b;c",  2).perl; > ("a", "b").Seq >> say comb(/\w+/, 
>> "a;b;c", 3).perl; > ("a", "b",
"c").Seq >> say comb(/\w+/, "a;b;c", 4).perl; > ("a", "b", "c").Seq >>
say comb(/\w+/, "a;b;c", True).perl; > ("a",).Seq
Same as above; True being interpreted as 1

>> say comb(/\w+/, "a;b;c",  2, True).perl; > Too many positionals passed; 
>> expected 2 or 3 arguments but got 4 in >
block  at  line 1
There's no syntax here that distinguishes 2, a positional parameter,
from True, also a positional parameter.

>> say comb(/\w+/, "a;b;c",  2, :True).perl; > Unexpected named argument 'True' 
>> passed in block  at 
file> line 1
The issue here is that :True is short for True => True, i.e. passing the
value True to the named parameter called "True", easy to get confused by
the error message here!
> Any help appreciated, Bill.

I hope the explanations make sense!
  - Timo

Re: getting comb to return match objects

[William Michels via perl6-users]

Hi Yary,

I went over this with Joe as well, and I was equally confused. So if I
understand what you're saying correctly, if we see something like
"Bool :$match" that says we should drop the dollar-sign ($) and enter
":match" to set "Bool" = True, and thus return the list of match
objects?

On another note (or possibly the same note), I tried code similar to
Joe's with fair success. I was able to get the REPL to understand a
"True" or "False" parameter, but never in conjunction with a "$limit"
parameter. Is this the correct behaviour, and why?

> #REPL
Nil
> say comb(/\w/, "a;b;c",  False).perl;
().Seq
> say comb(/\w/, "a;b;c",  True).perl;
("a",).Seq
> say comb(/\w+/, "a;b;c",  True).perl;
("a",).Seq
> say comb(/\w+/, "a;b;c",  2).perl;
("a", "b").Seq
> say comb(/\w+/, "a;b;c",  3).perl;
("a", "b", "c").Seq
> say comb(/\w+/, "a;b;c",  4).perl;
("a", "b", "c").Seq
> say comb(/\w+/, "a;b;c",  True).perl;
("a",).Seq
> say comb(/\w+/, "a;b;c",  2, True).perl;
Too many positionals passed; expected 2 or 3 arguments but got 4
  in block  at  line 1

> say comb(/\w+/, "a;b;c",  2, :True).perl;
Unexpected named argument 'True' passed
  in block  at  line 1

> $*VM
moar (2019.07.1)

Any help appreciated, Bill.




On Mon, Nov 11, 2019 at 9:46 AM yary  wrote:
>
> The syntax is in the declaration you pasted in your email
>
> > multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool 
> > :$match)
>
> The colon in "Bool :$match" makes it a named argument. Not sure where 
> definitive docs are, decent starting point is 
> https://docs.perl6.org/type/Signature#Positional_vs._named_arguments
>
>
> -y
>
>
> On Sun, Nov 10, 2019 at 11:18 PM Joseph Brenner  wrote:
>>
>> Thanks, that form does what I want--
>>
>> I don't see how I could've understood that from the docs, though.
>> For example, I don't see any place where the :match adverb is
>> mentioned for either the method or routine form of comb.
>>
>>
>>
>> On 11/10/19, Elizabeth Mattijsen  wrote:
>> > dd "foobar".comb(/./, :g, :match);
>> > (｢f｣ ｢o｣ ｢o｣ ｢b｣ ｢a｣ ｢r｣)
>> >
>> >> On 10 Nov 2019, at 23:46, Joseph Brenner  wrote:
>> >>
>> >> Can someone give me an example of how to use the comb routine to
>> >> return a list of match objects?
>> >>
>> >> The documentation here:
>> >>
>> >> https://docs.perl6.org/type/Str#routine_comb
>> >>
>> >> Mentions a boolean option to get match objects:
>> >>
>> >>> If $matcher is a Regex, each Match object is
>> >>> converted to a Str, unless $match is set.
>> >>
>> >> I gather that I must be reading this signature
>> >> wrong somehow, I can't get it to work:
>> >>
>> >>> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
>> >>> :$match)
>> >>
>> >> I keep trying variations of things like this:
>> >>
>> >>my @hits = comb(m/$search_pattern/, $chunk, 100, True);
>> >

Re: getting comb to return match objects

[yary]

The syntax is in the declaration you pasted in your email

> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf,
Bool :$match)

The colon in "Bool :$match" makes it a named argument. Not sure where
definitive docs are, decent starting point is
https://docs.perl6.org/type/Signature#Positional_vs._named_arguments


-y


On Sun, Nov 10, 2019 at 11:18 PM Joseph Brenner  wrote:

> Thanks, that form does what I want--
>
> I don't see how I could've understood that from the docs, though.
> For example, I don't see any place where the :match adverb is
> mentioned for either the method or routine form of comb.
>
>
>
> On 11/10/19, Elizabeth Mattijsen  wrote:
> > dd "foobar".comb(/./, :g, :match);
> > (｢f｣ ｢o｣ ｢o｣ ｢b｣ ｢a｣ ｢r｣)
> >
> >> On 10 Nov 2019, at 23:46, Joseph Brenner  wrote:
> >>
> >> Can someone give me an example of how to use the comb routine to
> >> return a list of match objects?
> >>
> >> The documentation here:
> >>
> >> https://docs.perl6.org/type/Str#routine_comb
> >>
> >> Mentions a boolean option to get match objects:
> >>
> >>> If $matcher is a Regex, each Match object is
> >>> converted to a Str, unless $match is set.
> >>
> >> I gather that I must be reading this signature
> >> wrong somehow, I can't get it to work:
> >>
> >>> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
> >>> :$match)
> >>
> >> I keep trying variations of things like this:
> >>
> >>my @hits = comb(m/$search_pattern/, $chunk, 100, True);
> >
>

Re: getting comb to return match objects

[Joseph Brenner]

Thanks, that form does what I want--

I don't see how I could've understood that from the docs, though.
For example, I don't see any place where the :match adverb is
mentioned for either the method or routine form of comb.



On 11/10/19, Elizabeth Mattijsen  wrote:
> dd "foobar".comb(/./, :g, :match);
> (｢f｣ ｢o｣ ｢o｣ ｢b｣ ｢a｣ ｢r｣)
>
>> On 10 Nov 2019, at 23:46, Joseph Brenner  wrote:
>>
>> Can someone give me an example of how to use the comb routine to
>> return a list of match objects?
>>
>> The documentation here:
>>
>> https://docs.perl6.org/type/Str#routine_comb
>>
>> Mentions a boolean option to get match objects:
>>
>>> If $matcher is a Regex, each Match object is
>>> converted to a Str, unless $match is set.
>>
>> I gather that I must be reading this signature
>> wrong somehow, I can't get it to work:
>>
>>> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool
>>> :$match)
>>
>> I keep trying variations of things like this:
>>
>>my @hits = comb(m/$search_pattern/, $chunk, 100, True);
>

Re: getting comb to return match objects

[Elizabeth Mattijsen]

dd "foobar".comb(/./, :g, :match);
(｢f｣ ｢o｣ ｢o｣ ｢b｣ ｢a｣ ｢r｣)

> On 10 Nov 2019, at 23:46, Joseph Brenner  wrote:
> 
> Can someone give me an example of how to use the comb routine to
> return a list of match objects?
> 
> The documentation here:
> 
> https://docs.perl6.org/type/Str#routine_comb
> 
> Mentions a boolean option to get match objects:
> 
>> If $matcher is a Regex, each Match object is
>> converted to a Str, unless $match is set.
> 
> I gather that I must be reading this signature
> wrong somehow, I can't get it to work:
> 
>> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool :$match)
> 
> I keep trying variations of things like this:
> 
>my @hits = comb(m/$search_pattern/, $chunk, 100, True);

getting comb to return match objects

[Joseph Brenner]

Can someone give me an example of how to use the comb routine to
return a list of match objects?

The documentation here:

https://docs.perl6.org/type/Str#routine_comb

Mentions a boolean option to get match objects:

> If $matcher is a Regex, each Match object is
> converted to a Str, unless $match is set.

I gather that I must be reading this signature
wrong somehow, I can't get it to work:

> multi subcomb(Regex:D $matcher, Str:D $input, $limit = Inf, Bool :$match)

I keep trying variations of things like this:

my @hits = comb(m/$search_pattern/, $chunk, 100, True);

[perl #124814] Roast rakudo skip/todo test:./S32-num/fatrat.t line:181 reason: 'FatRat arith + type objects'

[Zoffix Znet via RT]

Re-filed with more details on the issue in 
https://github.com/rakudo/rakudo/issues/1830

[perl #126897] [BUG] Slip objects deparse as List

[Zoffix Znet via RT]

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote:
> so no
> further tests needed
> 
> 
> Liz

And in addition it's covered by tests for another slip bug:
https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff

Closing.

[perl #126897] [BUG] Slip objects deparse as List

[Zoffix Znet via RT]

On Sun, 13 Dec 2015 13:15:56 -0800, elizabeth wrote:
> so no
> further tests needed
> 
> 
> Liz

And in addition it's covered by tests for another slip bug:
https://github.com/perl6/roast/commit/7eea834e98090b1f571dabe719784eaa0b0207ff

Closing.

[perl #124226] [BUG] Opportunity to catch syntactically detectable calls to attribute-accessing methods on type objects in Rakudo

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Still reproducible (2017.11,HEAD(e5b660e))

On 2015-04-01 13:19:33, masak wrote:
> <[Tux]> m: class C { has Int $!x; method foo { ($!x, my $b) =
> (1,2);}};C.foo
> 19:45 <+camelia> rakudo-moar 6caf1d: OUTPUT«Cannot look up attributes
> in a type object␤ in method foo [...]
> <[Tux]> is that explainable?
>  you're calling C.foo, the .foo method on the type object C
>  the type object doesn't really properly have an $!x
>  m: class C { has Int $!x; method foo { ($!x, my $b) =
> (1,2);}}; C.new.foo
>  rakudo-moar 6caf1d: ( no output )
>  that works.
>  "Cannot look up attributes in a type object" is an
> implementor-centric error message, not a user-centric one
>  TimToady: "Instance attribute used in non-instance method
> call"? :)
>  TimToady: actually, that error message could fail statically
> in this case.
>  since C is already resolved at compile time.
>  no need to make it survive until runtime and then fail.
> [...]
>  no-one else liked the idea of statically erroring out with
> "call will never work" for the C.foo case where C is already
> statically resolved?
>  masak: I do
>  masak: Could work, but can't methods be marked as instance-
> only?
>  masak: the earlier errors are reported the better
>  masak: How does the compiler decide that it will never work?
> and when?
>  Because then, any use of $!foo could simply mark the method as
> instance-only
>  And the error message could be simpler.
>  "Method foo can only be called on an instance of C, not on C
> itself."
>  (compiler hints)++ if we can reasonably have them.
>  I guess, if you declare the sig right, all the info is easy
> to get at. But without that, it seems like a bit of guessing for the
> compiler to do it.
>  PerlJam: compiler sees the call C.foo, and has already set a
> flag that the foo method in class C accesses an attribute. boom.
> * masak submits rakudobug
>  "Method foo can only be called on an instance of C, not on C
> itself, because C.foo accesses instance attribute $!x."
>  neat. +1
>  masak: flagging methods like that seems like quite a bit of
> bookkeeping for marginal benefit.
>  really? seems worth it to me...
>  it's a small hash somewhere in the compiler.
>  %accattr = True;
>  It could be a boolean flag (instance-only) and an array of
> further explanations
> <[Coke]> masak: I think you mean a compile-time static check, not a
> static static check. ;)
>  [Coke]: yes. thank you. I meant... that, what you said.

[perl #78200] [BUG] LTA error message when using attributes on type objects

[Daniel Green via RT]

On Sun, 05 Nov 2017 07:54:01 -0800, alex.jakime...@gmail.com wrote:
> FWIW the error message seems to be coming from MoarVM:
> https://github.com/MoarVM/MoarVM/blob/ad86184681590c81fc25b9e90b406e5163098796/src/6model/reprconv.c#L607
> (many similar lines like this in that file)
> 
> On 2017-11-05 07:46:17, alex.jakime...@gmail.com wrote:
> > Hey Tobias, it looks like you've been working on this ticket for over
> > two
> > years. How is it going?
> > On 2015-04-09 12:09:55, FROGGS.de wrote:
> > > How about:
> > >
> > > (before)
> > > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > > Cannot look up attributes in a type object
> > > in method foo at -e:1
> > > in block  at -e:1
> > >
> > > (after)
> > > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > > Cannot look up attributes in a type object. Perhaps you need to
> > > instanciate first?
> > > in method foo at -e:1
> > > in block  at -e:1


The error message was recently improved in 
https://github.com/MoarVM/MoarVM/commit/68a18b4f22553bfd96c47c8d7453af881772b3d4#diff-be9fec83f5b58ba42962ded7b65de075

$ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
Cannot look up attributes in a A type object
  in method foo at -e line 1
  in block  at -e line 1

[perl #78200] [BUG] LTA error message when using attributes on type objects

[Aleks-Daniel Jakimenko-Aleksejev via RT]

FWIW the error message seems to be coming from MoarVM:
https://github.com/MoarVM/MoarVM/blob/ad86184681590c81fc25b9e90b406e5163098796/src/6model/reprconv.c#L607
(many similar lines like this in that file)

On 2017-11-05 07:46:17, alex.jakime...@gmail.com wrote:
> Hey Tobias, it looks like you've been working on this ticket for over two
> years. How is it going?
> On 2015-04-09 12:09:55, FROGGS.de wrote:
> > How about:
> >
> > (before)
> > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > Cannot look up attributes in a type object
> > in method foo at -e:1
> > in block  at -e:1
> >
> > (after)
> > $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> > Cannot look up attributes in a type object. Perhaps you need to
> > instanciate first?
> > in method foo at -e:1
> > in block  at -e:1

[perl #78200] [BUG] LTA error message when using attributes on type objects

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Hey Tobias, it looks like you've been working on this ticket for over two
years. How is it going?
On 2015-04-09 12:09:55, FROGGS.de wrote:
> How about:
>
> (before)
> $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> Cannot look up attributes in a type object
> in method foo at -e:1
> in block  at -e:1
>
> (after)
> $ perl6-m -e 'class A { has $!x; method foo { say $!x } }; A.foo'
> Cannot look up attributes in a type object. Perhaps you need to
> instanciate first?
> in method foo at -e:1
> in block  at -e:1

[perl #132149] [BUG] Some Method objects use wrong .gist method

[via RT]

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


Method objects have their own `.gist` method[^1] that just print `.name`. 
However, under some
circumstances, that method is lost, and `Mu::gist` is used instead:

 m: .comb.^methods.grep(*.name eq 'eager').say
 rakudo-moar 7af339: OUTPUT: «(Method+{<anon|61058032>}.new)␤»

I tried to fix it and failed, but found some facts about the bug that might 
give a hint:

*) The problematic methods has `is nodal` trait on them (which mixes in a 
role), but NOT all nodal
methods have this issue
*) (90% sure this is what happened) If you add an only `method z is nodal {}` 
to src/core/Any.pm, the bug doesn't appear
*) If you add a `multi method z is nodal {}` to src/core/Any.pm the bug occurs
*) If you do the same thing with a regular class, it doesn't happen. BTW: `Any` 
is augmented in core
*) .file on the method gives src/core/Method.pm. However, if you modify Mu.gist 
to append some string,
you'll see that it's Mu's method that gets called.

 m: my $m = .comb.^methods.grep(*.name eq 'eager').head; dd 
$m.^lookup('gist').cando(\($m)).head.file
 rakudo-moar 7af339: OUTPUT: «"SETTING::src/core/Method.pm"␤»

*) Even if you make Method.gist an `only` method, the Mu::gist one is still the 
one that gets called
*) If you implement only or multi method `gist` in the role that `is nodal` 
mixed in[^2], trying to
call .gist on the buggy method gives "Cannot invoke this object (REPR: 
Null; VMNull)"

[1] 
https://github.com/rakudo/rakudo/blob/045ef448b62c045630abb8e167cc45d1f9fe6902/src/core/Method.pm#L4
[2] 
https://github.com/rakudo/rakudo/blob/7af339b91d2a56a4a4eb065952cd548c188bd124/src/core/traits.pm#L357

[perl #125293] [BUG] Match objects don't roundtrip through .perl

[Christian Bartolomaeus via RT]

The tests in question have been unfudged with roast commit 
https://github.com/perl6/roast/commit/6db316eaae. (This was probably fixed with 
merging the 'uncurse' branch.)

The last example from the last comment (using EVAL) works as expected, too:

$ ./perl6-m -e 'say Map.new("a", 42).perl.EVAL'
Map.new((:a(42)))

I'm closing this ticket as 'resolved'.

[perl #129008] [BUG] Pair.perl confused by some type objects

[Brian S. Julin via RT]

On Mon, 11 Sep 2017 16:53:15 -0700, b...@abrij.org wrote:
> On Mon, 11 Sep 2017 13:35:54 -0700, zef...@fysh.org wrote:
> > Brian S. Julin via RT wrote:
> > >Fixed in 2017.6 or thereabouts.
> > 
> > Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
> > 2017-06-15.
> > 
> > -zefram
> 
> 
> Tests added in roast 9a09b4ee, resolving this ticket.

ACTUALLY resolving this ticket :-)

[perl #129008] [BUG] Pair.perl confused by some type objects

[Brian S. Julin via RT]

On Mon, 11 Sep 2017 13:35:54 -0700, zef...@fysh.org wrote:
> Brian S. Julin via RT wrote:
> >Fixed in 2017.6 or thereabouts.
> 
> Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
> 2017-06-15.
> 
> -zefram


Tests added in roast 9a09b4ee, resolving this ticket.

Re: [perl #129008] [TESTNEEDED] Pair.perl confused by some type objects

[Zefram via RT]

Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.

Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.

-zefram

Re: [perl #129008] [TESTNEEDED] Pair.perl confused by some type objects

[Zefram]

Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.

Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.

-zefram

[perl #129008] [TESTNEEDED] Pair.perl confused by some type objects

[Brian S. Julin via RT]

On Fri, 19 Aug 2016 19:00:53 -0700, zef...@fysh.org wrote:
> Pair.perl produces incorrect output for some type objects:
> 
> > ((Int) => 2).perl
> Int => 2
> > ((Int) => 2).perl.EVAL.perl
> :Int(2)
> 
> Following the fix for [perl #126890] it's correct for most type
> objects:
> 
> > ((Pair) => 2).perl
> (Pair) => 2
> 
> but if given the type object for a type that .^does(Numeric) it
> mistakes
> the type object for a definite numeric value.  It follows the code
> branch
> that's intended to produce "3 => 2" rather than "(3) => 2", so it
> fails
> to parenthesise the type object name.
> 
> If the type object is Num, it gets into another special-case code
> branch:
> 
> > ((Num) => 3).perl
> Cannot unbox a type object
>   in block  at  line 1
> 
> There's a related failure resulting from mistaking the Str type object
> for a string:
> 
> > ((Str) => 2).perl
> Use of uninitialized value of type Str in string context.
> Methods .^name, .perl, .gist, or .say can be used to stringify it to
> something meaningful.  in block  at  line 1
> Str => 2
> 
> and another resulting from mistaken handling of the Bool type object
> in
> the value slot:
> 
> > :a(Bool).perl
> :!a
> 
> There needs to be some :D or equivalent on all of these type checks.
> 
> -zefram

Fixed in 2017.6 or thereabouts.  Tests needed.

[perl #123015] [RFC] methods for accessing binary data in Buf objects

[Brian S. Julin via RT]

On Mon, 20 Oct 2014 07:01:07 -0700, moritz wrote:
> On Mon Oct 20 06:54:16 2014, abraxxa wrote:
> > As discussed on IRC mainly with moritz I'd need a way to get the
> > number of bytes, not elements, of a Buf object so it can be looped
> > and
> > each byte accessed with $buf.[$idx].
> > I'm requiring this in DBDish::Oracle for passing UTF-16 encoded
> > values
> > and their byte-length to the OCI C library using NativeCall.
> 
> Another use case: cryptography, which typically works on the byte
> level, even for multi-byte encodings.


A lot of time has passed and we have has the first part for quite some time.

$ perl6 -e '.bytes.say for buf8.new(1,2,3), buf16.new(1,2,3), buf32.new(1,2,3), 
buf64.new(1,2,3)'
3
6
12
24

...which is both specced and already tested.  Also as a Container type
you get .of:

$ perl6 -e '.of.say for Buf[int8].new(1,2,3), Buf[uint16].new(1,2,3), 
Buf[int32], Buf[uint64]'
(int8)
(uint16)
(int32)
(uint64)

...and the native types can be nativesizeof'd

$ perl6 -e 'use NativeCall; nativesizeof(.of).say for Buf[int8].new(1,2,3), 
Buf[uint16].new(1,2,3), Buf[int32], Buf[uint64]'
1
2
4
8

Also there are ways to finagle the second need with NativeCall:

$ perl6 -e 'use NativeCall; my $b16 = buf16.new(1,2,3); my $b8 = 
nativecast(CArray[uint8], $b16); $b8[^6].say'
(1 0 2 0 3 0)

...though internally this relies on some GC manipulations and the
details on exactly if/when it becomes fragile aren't documented.

Granted a lot more could be done to make this, and endianness conversions 
easier,
e.g. safe and optimized indexing adverbs like buf32.new(1,2)[^8]:swab8 might be
nice, as well as having types that carry their endianness information around 
with them,
but I think that falls in the 6.d-and-later design discussion category rather 
than RT.

So I'd vote to 'resolve' this ticket, and maybe if the next person who picks
it up agrees, they should do so.

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2017-07-13 08:18:20, alex.jakime...@gmail.com wrote:
> On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> > This only applies if you call .stdout or .stderr *and* never close
> > them.
>
> Hm, isn't it fixed now? Similarly to
> https://github.com/perl6/doc/issues/1304 ?

Ah, no, it's not. It's a completely different issue. Here we are intentionally
running out of handles. nvm

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Aleks-Daniel Jakimenko-Aleksejev via RT]

On 2017-07-12 22:49:43, ug...@cpan.org wrote:
> This only applies if you call .stdout or .stderr *and* never close them.

Hm, isn't it fixed now? Similarly to https://github.com/perl6/doc/issues/1304 ?

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Nick Logan via RT]

This only applies if you call .stdout or .stderr *and* never close them.

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Will Coleda via RT]

On Mon, 20 Jul 2015 20:09:39 -0700, r...@hoelz.ro wrote:
> See the attached script.

Still dying with version 2017.06-13-g6b634a369 built on MoarVM version 
2017.06-2-gcc27eebf

-- 
Will "Coke" Coleda

[perl #125656] [CONC] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[Will Coleda via RT]

On Mon, 20 Jul 2015 20:09:39 -0700, r...@hoelz.ro wrote:
> See the attached script.

Still dying with version 2017.06-13-g6b634a369 built on MoarVM version 
2017.06-2-gcc27eebf

-- 
Will "Coke" Coleda

[perl #128041] [JVM] Failing tests for equivalence of Buf objects

[Zoffix Znet via RT]

On Sat, 30 Apr 2016 11:16:44 -0700, barto...@gmx.de wrote:
> Starting with rakudo commit fe2be65806 two tests in S16-io/supply.t
> start to fail with rakudo-j. The following rakudo commit 463e7589a1
> seems to change the code path for the tests in question, but also
> makes them fail. Only if one reverts both commits, the tests pass
> again.
> 
> The following code is a shortened version of one of the failing tests.
> Probably it could be golfed further.
> 
> $ perl6-j -e 'my $f = "foo"; spurt($f,"a"); my $h = open($f); my $s =
> $h.Supply(:size(1),:bin); my $x; $s.tap( { $x = $_ } ); $h.close; my
> $y = Buf[uint8].new(ord "a"); say $x; say $y; say $x eqv $y'
> Buf[uint8]:0x<61>
> Buf[uint8]:0x<61>
> False
> 
> On rakudo-m the last comparison returns True:
> 
> $ perl6-m -e 'my $f = "foo"; spurt($f,"a"); my $h = open($f); my $s =
> $h.Supply(:size(1),:bin); my $x; $s.tap( { $x = $_ } ); $h.close; my
> $y = Buf[uint8].new(ord "a"); say $x; say $y; say $x eqv $y'
> Buf[uint8]:0x<61>
> Buf[uint8]:0x<61>
> True


Golfed it a bit (buf8 is what the Supply uses):

 r: dd buf8 eqv Buf[uint8]
 rakudo-moar 0c6281: OUTPUT: «Bool::True␤»
 ..rakudo-jvm fb4f16: OUTPUT: «Bool::False␤»

[perl #130458] [REGRESSION] NFC and NFD objects no longer smartmatch as strings ("7\x[308]".NFD ~~ /^ \d+ $/)

[Christian Bartolomaeus via RT]

Unfortunately commit 8d35951 breaks the build on JVM. It dies during stage 
parse with

Error while compiling, type X::Parameter::InvalidType
  suggestions: ()
  typename: Uni
 at line 32953, near " $uni) {  "
  in panic (gen/jvm/stage2/NQPHLL.nqp:348)
  [...]

Type Uni is not usable with rakudo-j:

$ perl6-j -e 'my Uni $foo'
===SORRY!===
Type 'Uni' is not declared
at -e:1
--> my Uni⏏ $foo
Malformed my
at -e:1
--> my⏏ Uni $foo

I'd suggest to add a special case for jvm, so that fix from commit 8d35951 is 
not applied there. I opened a PR for that: 
https://github.com/rakudo/rakudo/pull/980

Re: [perl #130458] [REGRESSION] NFC and NFD objects no longer smartmatch as strings ("7\x[308]".NFD ~~ /^ \d+ $/)

[Elizabeth Mattijsen]

Fixed with 8d35951 , tests needed

> On 30 Dec 2016, at 18:59, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
> <perl6-bugs-follo...@perl.org> wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #130458]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=130458 >
> 
> 
> Code:
> say "7\x[308]".NFC ~~ /^ \d+ $/
> 
> 
> Result (2015.12,2016.10):
> ｢7̈｣
> 
> 
> Result (2016.11,HEAD):
> ｢55｣
> 
> 
> Previously it worked with NFC objects as if they were strings, which 
> intuitively makes sense. However, I'm not going to claim that this is what it 
> should do, I'm just pointing out that the behavior was changed.
> 
> Right now it works with the .ord of the first character, this is probably 
> less than awesome.
> 
> The change is a result of both 
> https://github.com/rakudo/rakudo/commit/05b65d0b1263b2d6ae974e2bf0d0d7f17df11e38
>  and 
> https://github.com/rakudo/rakudo/commit/33eeb323373c7b01f2d791779a877838369a11e8

[perl #130458] [REGRESSION] NFC and NFD objects no longer smartmatch as strings ("7\x[308]".NFD ~~ /^ \d+ $/)

[via RT]

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


Code:
say "7\x[308]".NFC ~~ /^ \d+ $/


Result (2015.12,2016.10):
｢7̈｣


Result (2016.11,HEAD):
｢55｣


Previously it worked with NFC objects as if they were strings, which 
intuitively makes sense. However, I'm not going to claim that this is what it 
should do, I'm just pointing out that the behavior was changed.

Right now it works with the .ord of the first character, this is probably less 
than awesome.

The change is a result of both 
https://github.com/rakudo/rakudo/commit/05b65d0b1263b2d6ae974e2bf0d0d7f17df11e38
 and 
https://github.com/rakudo/rakudo/commit/33eeb323373c7b01f2d791779a877838369a11e8

[perl #129014] [BUG] Range.new confused by type objects

[via RT]

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


The Range class allows most values to be used as endpoints, even things
such as type objects.  But certain type objects get mistaken for defined
objects, causing silly error results:

> Range.new(List, Pair).perl
List..Pair
> Range.new(Seq, List).perl
Seq objects are not valid endpoints for Ranges
  in block  at  line 1
> Range.new(List, Int).perl
List..Int
> Range.new(Int, List).perl
Use of uninitialized value of type List in numeric context  in block  at 
 line 1
Use of uninitialized value of type List in numeric context  in block  at 
 line 1
Invocant requires an instance of type Int, but a type object was passed.  Did 
you forget a .new?
  in block  at  line 1

These type objects should be either successfully allowed or cleanly
prohibited.  They don't have the disadvantages that the corresponding
defined objects would have, so they should probably be allowed.

-zefram

Re: [perl #129007] [BUG] Baggy.perl confused by type objects

[Zefram]

Additional: it also gets confused by some Pair objects as keys:

> (("a b" => "c") => 2).Bag.perl
("a b" => "c"=>2).Bag
> (("a b" => "c") => 2).Bag.perl.EVAL.perl
Type check failed in assignment; expected Int but got Pair (:c(2))
  in block  at EVAL_15 line 1
  in block  at  line 1

Invoking Pair.perl would fix this too.

-zefram

[perl #129008] [BUG] Pair.perl confused by some type objects

[via RT]

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


Pair.perl produces incorrect output for some type objects:

> ((Int) => 2).perl
Int => 2
> ((Int) => 2).perl.EVAL.perl
:Int(2)

Following the fix for [perl #126890] it's correct for most type objects:

> ((Pair) => 2).perl
(Pair) => 2

but if given the type object for a type that .^does(Numeric) it mistakes
the type object for a definite numeric value.  It follows the code branch
that's intended to produce "3 => 2" rather than "(3) => 2", so it fails
to parenthesise the type object name.

If the type object is Num, it gets into another special-case code branch:

> ((Num) => 3).perl
Cannot unbox a type object
  in block  at  line 1

There's a related failure resulting from mistaking the Str type object
for a string:

> ((Str) => 2).perl
Use of uninitialized value of type Str in string context.
Methods .^name, .perl, .gist, or .say can be used to stringify it to something 
meaningful.  in block  at  line 1
Str => 2

and another resulting from mistaken handling of the Bool type object in
the value slot:

> :a(Bool).perl
:!a

There needs to be some :D or equivalent on all of these type checks.

-zefram

[perl #129007] [BUG] Baggy.perl confused by type objects

[via RT]

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


> ((Nil) => 2).Bag.perl
(Nil=>2).Bag
> ((Nil) => 2).Bag.perl.EVAL.perl
("Nil"=>2).Bag

.perl.EVAL doesn't round-trip a Bag where any of the keys in the bag
deparses as an identifier.  This happens because it's rolling its own
Pair deparsing and runs into autoquoting.  This is the same problem that
was seen with Pair.perl in [perl #126890].  The reliable fix would be
for Baggy.perl to construct Pair objects and call .perl on them, so that
the logic to handle this only needs to be in one place (Pair.perl).

-zefram

[perl #128041] [JVM] Failing tests for equivalence of Buf objects

[via RT]

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


Starting with rakudo commit fe2be65806 two tests in S16-io/supply.t start to 
fail with rakudo-j. The following rakudo commit 463e7589a1 seems to change the 
code path for the tests in question, but also makes them fail. Only if one 
reverts both commits, the tests pass again.

The following code is a shortened version of one of the failing tests. Probably 
it could be golfed further.

$ perl6-j -e 'my $f = "foo"; spurt($f,"a"); my $h = open($f); my $s = 
$h.Supply(:size(1),:bin); my $x; $s.tap( { $x = $_ } ); $h.close; my $y = 
Buf[uint8].new(ord "a"); say $x; say $y; say $x eqv $y'
Buf[uint8]:0x<61>
Buf[uint8]:0x<61>
False

On rakudo-m the last comparison returns True:

$ perl6-m -e 'my $f = "foo"; spurt($f,"a"); my $h = open($f); my $s = 
$h.Supply(:size(1),:bin); my $x; $s.tap( { $x = $_ } ); $h.close; my $y = 
Buf[uint8].new(ord "a"); say $x; say $y; say $x eqv $y'
Buf[uint8]:0x<61>
Buf[uint8]:0x<61>
True

[perl #127402] Set.hash stringifies its objects

[via RT]

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


[09:58:03]  m: my $s = set( $() ); dd $s.hash  # argh, 
uncaught bug  :-(
[09:58:03]  <+camelia>  rakudo-moar 86a90b: OUTPUT«Hash %e = {"a b c" => 
Bool::True}␤»
[10:04:38]  I expected: Hash[Any,Any] % = (my Any %{Any} = (("a", 
"b", "c")) => 1)
[10:05:06]  well, => Bool::True

Re: [perl #126891] [BUG] module objects badly behaved for type checks

[Zefram]

Elizabeth Mattijsen via RT wrote:
>This seems to apply to any variable type and any PseudoStash:

Further generalisation: it also happens for any package object (GLOBAL,
MAIN) and any role object (Iterable, Dateish).  In both cases, the
.^isa misbehaviour is seen as well as the actual ability to bypass
type constraints.

-zefram

[perl #126541] Expose native file descriptor for handle like objects.

[jn...@jnthn.net via RT]

On Mon Nov 02 10:54:27 2015, jns...@gellyfish.co.uk wrote:
> Hi,
> In a number of places in the design documents it is suggested that
> certain functionality on files (e.g. fcntl, ioctl) or sockets (e.g.
> getsockname, setsockopt) should be provided by external modules via
> the NativeCall interface, however the majority of these C library
> functions require the native "file descriptor" as one of the
> arguments.
> 
> It would be useful to module authors if the OS platform (or runtime
> environment) idea of a "file descriptor" was available through some
> accessor on the IO::Handle, IO::Socket etc
> 
> Where libuv is being used then this is available through
> 
> int uv_fileno(const uv_handle_t* handle, uv_os_fd_t* fd)
> 
> If libuv is being bypassed for sync operations at some later point
> then the descriptor will be available directly.
> 
> My personal fear is that if this is not provided for the use in
> modules that require them then people will just bypass IO::*
> altogether creating an interoperability nightmare.
> 
Agree, it's wise to provide a way to get it for such scenarios. Added  a 
.native-descriptor on file handles and sockets now. As the name suggests, it's 
native, as in platform specific (so you can expect to get a HANDLE value on 
Windows, for example). Tests in S32-io/native-descriptor.t.

Re: [perl #126891] [BUG] module objects badly behaved for type checks

[Elizabeth Mattijsen]

Zefram,

> On 13 Dec 2015, at 05:56, Zefram (via RT) <perl6-bugs-follo...@perl.org> 
> wrote:
> 
> # New Ticket Created by  Zefram 
> # Please include the string:  [perl #126891]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=126891 >
> 
> 
>> my Int $a = CORE
>> $a.WHAT.say
> (CORE)
>> CORE.^isa(Int)
> Cannot call isa(Perl6::Metamodel::ModuleHOW: CORE, Int); none of these 
> signatures match:
>(Mu \SELF: Mu $type, *%_)
>(Mu \SELF: Str:D $name, *%_)
>  in block  at :1
>> (sub (Int $a) { 1 })(CORE)
> Type check failed in binding $a; expected Int but got CORE
>  in sub  at :1
>  in block  at :1
> 
> CORE is a module object; other module objects behave similarly.  As shown
> above, they can be assigned to type-constrained variables despite not
> meeting the type constraint.  Additionally, the .^isa method fails to
> operate on them; don't know whether these two faults are really related.
> Type constraint does apply as expected to a subroutine parameter.

thanks for submitting these tickets!

Some further data points:

This seems to apply to any variable type and any PseudoStash:

$ 6 'my Str $a = MY; say $a'
(MY)

Oddly enough, binding *does* fail with a typecheck error:

$ 6 'my Str $a := GLOBAL'
Type check failed in binding; expected Str but got GLOBAL
  in block  at -e:1




Liz

[perl #126897] [BUG] Slip objects deparse as List

[via RT]

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


$ perl6 -e 'slip(2,3).WHAT.say; slip(2,3).perl.EVAL.WHAT.say'
(Slip)
(List)

The .perl method on Slip ought to produce an expression that specifically
constructs a Slip object.

-zefram

Re: [perl #126897] [BUG] Slip objects deparse as List

[Elizabeth Mattijsen]

> On 13 Dec 2015, at 20:53, Zefram (via RT)  
> wrote:
> 
> # New Ticket Created by  Zefram 
> # Please include the string:  [perl #126897]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=126897 >
> 
> 
> $ perl6 -e 'slip(2,3).WHAT.say; slip(2,3).perl.EVAL.WHAT.say'
> (Slip)
> (List)
> 
> The .perl method on Slip ought to produce an expression that specifically
> constructs a Slip object.

Thanks for the report.

Fixed with 82f273b65c9133f4389

There is some test breakage, but that will be fixed asap, so no further tests 
needed


Liz

[perl #126891] [BUG] module objects badly behaved for type checks

[via RT]

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


> my Int $a = CORE
> $a.WHAT.say
(CORE)
> CORE.^isa(Int)
Cannot call isa(Perl6::Metamodel::ModuleHOW: CORE, Int); none of these 
signatures match:
(Mu \SELF: Mu $type, *%_)
(Mu \SELF: Str:D $name, *%_)
  in block  at :1
> (sub (Int $a) { 1 })(CORE)
Type check failed in binding $a; expected Int but got CORE
  in sub  at :1
  in block  at :1

CORE is a module object; other module objects behave similarly.  As shown
above, they can be assigned to type-constrained variables despite not
meeting the type constraint.  Additionally, the .^isa method fails to
operate on them; don't know whether these two faults are really related.
Type constraint does apply as expected to a subroutine parameter.

-zefram

[perl #126835] Signature objects don't smartmatch

[via RT]

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


class C{}; my $sig1 = (my method (C: Int) {}).signature; my $sig2 = (my method 
(C: Int) {}).signature; say so $sig1 ~~ $sig2;

# OUTPUT«False␤»
# I would expect True for a smartmatch of copypasta signatures

class C{}; my $sig1 = (my method (C: Int) {}).signature; my $sig2 := $sig1; say 
so $sig1 ~~ $sig2;

# OUTPUT«False␤»

# The same signature bound to two variables is equil to itself. So the problem 
seams to be with ~~
class C{}; my $sig1 = (my method (C: Int) {}).signature; my $sig2 := $sig1; say 
so $sig1 === $sig2;
# OUTPUT«True␤»

[perl #111498] [BUG] something weird is going on with object hashes and mixed-in objects in Rakudo

[Christian Bartolomaeus via RT]

Current behaviour:

$ perl6-m -e 'my $r1 = role { method foo() { 5 } }; my $r2 = role { method 
foo() { 7 } }; my %hash{Any}; %hash{"quux" but $r1} = 9; %hash{"quux" but $r2} 
= 11; say %hash.keys>>.foo'
(5 7)

Is that the expected answer?

[perl #126541] Expose native file descriptor for handle like objects.

[via RT]

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


Hi,
In a number of places in the design documents it is suggested that certain 
functionality on files (e.g. fcntl, ioctl) or sockets (e.g. getsockname, 
setsockopt) should be provided by external modules via the NativeCall 
interface, however the majority of these C library functions require the native 
"file descriptor" as one of the arguments.

It would be useful to module authors if the OS platform (or runtime 
environment) idea of a "file descriptor" was available through some accessor on 
the IO::Handle, IO::Socket etc

Where libuv is being used then this is available through

int uv_fileno(const uv_handle_t* handle, uv_os_fd_t* fd)

If libuv is being bypassed for sync operations at some later point then the 
descriptor will be available directly.

My personal fear is that if this is not provided for the use in modules that 
require them then people will just bypass IO::* altogether creating an 
interoperability nightmare.

Thanks.

[perl #126520] Proxy objects - frequent FETCHs

[via RT]

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


Consider the following, which should be a simple and conventional use of Perl 6 
Proxy objects:

class C {
has $!foo;
method foo is rw {
say "foo";
$!foo;
}

has $!bar;
method bar is rw {
Proxy.new(
say "proxy new";
FETCH => sub ($) {
say "bar fetch";
$!bar
},
STORE => sub ($, $v) {
say "bar store";
$!bar = $v;
},
);
}
}

my $c = C.new;
say "FETCHES";
$c.foo;
$c.bar;
say "STORES";
$c.foo++;
$c.bar++;

OUTPUT:

FETCHES
foo
proxy new
bar fetch
bar fetch
bar fetch
STORES
foo
proxy new
bar fetch
bar fetch
bar fetch
bar fetch
bar fetch
bar fetch
bar fetch
bar store

===
In the above example, the bar proxy is called 10x whereas foo is called twice.

In particular, the proxy FETCH is called 7X to do a simple increment.

I'm raising this because this is the 'hot path' in projects such as 
https://github.com/p6-pdf/perl6-PDF-Tools.

Would like to see this reduced, if possible.

[perl #126462] Bug returning objects directly from called methods using some form of named arguments

[via RT]

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


Two samples of code for which the problem is closely related

The first problem;

   return MongoDB::Cursor.new(
 collection  => self,
 OP_REPLY=> $OP_REPLY,
 criteria=> %@criteria
   );

Generates the error; 'Default constructor for 'MongoDB::Cursor' only 
takes named arguments'


The second problem;

   return self.find-and-modify(
 $criteria, $projection, :$remove, :$update, :$sort,
 :$new, :$upsert
   );

Generates: 'Too many positionals passed; expected 1 to 3 arguments but 
got 8'

The different errors are caused by the order of testing steps done by 
perl6. The named arguments are converted to or seen as positionals in 
some way when it is used together with the return statement.


To make it work I had to resort to the following.

   my $c = MongoDB::Cursor.new(
 collection  => self,
 OP_REPLY=> $OP_REPLY,
 criteria=> %@criteria
   );

   return $c;


and for the second the same way

   my $h = self.find-and-modify(
$criteria, $projection, :$remove, :$update, :$sort,
:$new, :$upsert
   );

   return $h;

perl6 version 2015.09-346-g0251b52 built on MoarVM version 
2015.09-74-gedc44b5

Bug returning objects directly from called methods using some form of named arguments

[mt1957]

Two samples of code for which the problem is closely related

The first problem;

  return MongoDB::Cursor.new(
collection  => self,
OP_REPLY=> $OP_REPLY,
criteria=> %@criteria
  );

Generates the error; 'Default constructor for 'MongoDB::Cursor' only 
takes named arguments'



The second problem;

  return self.find-and-modify(
$criteria, $projection, :$remove, :$update, :$sort,
:$new, :$upsert
  );

Generates: 'Too many positionals passed; expected 1 to 3 arguments but 
got 8'




To make it work I had to resort to the following.

  my $c = MongoDB::Cursor.new(
collection  => self,
OP_REPLY=> $OP_REPLY,
criteria=> %@criteria
  );

  return $c;


and for the second the same way

  my $h = self.find-and-modify(
$criteria, $projection, :$remove, :$update, :$sort,
:$new, :$upsert
  );

  return $h;

perl6 version 2015.09-346-g0251b52 built on MoarVM version 
2015.09-74-gedc44b5


Greetings
Marcel Timmerman

[perl #123037] [BUG] .gist on typed array shows (Any) instead of real type objects

[Christian Bartolomaeus via RT]

Also masak's example works now as expected:

$ perl6 -e 'my Int @a; @a[4]++; say @a[0]; say @a'
(Int)
[(Int) (Int) (Int) (Int) 1]

I added a test (without say, but using .gist) to S09-typed-arrays/arrays.t with 
commit https://github.com/perl6/roast/commit/4ec7087158.

I'm closing this ticket as 'resolved'.

Re: Bug creating objects using some form of named arguments

[mt1957]

The trouble I get at the moment is an error generared by the following 
piece of code


  return MongoDB::Cursor.new(
collection  => self,
OP_REPLY=> $OP_REPLY,
criteria=> %@criteria
  );

It generates the error;

Default constructor for 'MongoDB::Cursor' only takes named arguments
  in method throw at 
/home/marcel/Software/lib/perl6/share/perl6/runtime/CORE.setting.moarvm:1

...

In the previous mails I've tried to golf it but failed, so there is 
something in my programs which triggers this error but I don't know 
where and why.


I could solve it by using other named parameter formats but the 
following code rewrite (which now doesn't error) seems to point to the 
combination with the return statement;


  my $c = MongoDB::Cursor.new(
collection  => self,
OP_REPLY=> $OP_REPLY,
criteria=> %@criteria
  );

  return $c;

perl6 version 2015.09-162-gdd6c855 built on MoarVM version 
2015.09-39-g1434283


Greetings
Marcel Timmerman

Bug creating objects using some form of named arguments

[mt1957]

Hi

Below a set of tests where all object creates are done well except for 
the last one using a sub or method returning the created object.



class X {
  has Str $.a;
}

my X $x .= new(a => 'abc');
say "\$x = {$x.perl}";

$x .= new(:a('abc'));
say "\$x = {$x.perl}";

$x .= new :a('abc');
say "\$x = {$x.perl}";

$x .= new :a;
say "\$x = {$x.perl}";

class X::Y {
  has Str $.a;
  has Str $.b;
}

my  $y = X::Y.new(
  a => 'abc',
  b => 'def'
);
say "\$y = {$y.perl}";

$y .= new( :a('abc'), :b('def'));
say "\$y = {$y.perl}";

$y .= new :a('abc') :b('def');
say "\$y = {$y.perl}";

$y .= new :a :b;
say "\$y = {$y.perl}";



my X::Y $z = xy( );
say "\$z = {$z.perl}";

sub xy ( Str $s1, Str $s2 --> X::Y ) {
  return X::Y.new(
a => 'abc',
b => 'def'
  );
}


The output and error returned is

$x = X.new(a => "abc")
$x = X.new(a => "abc")
$x = X.new(a => "abc")
$x = X.new(a => "abc")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
Too few positionals passed; expected 2 arguments but got 1
  in sub xy at named-parameters.pl6:46
  in block  at named-parameters.pl6:43


I have to explicitly rewrite it into one of the colon forms (';')

my  $y = X::Y.new(
  :a('abc'),
  :b('def')
);

Greets,
M

Re: Bug creating objects using some form of named arguments

[mt1957]

On 09/28/2015 07:16 PM, mt1957 wrote:

False alarm, had a typing error in the code so, mea culpa poli :-[ .



Hi

Below a set of tests where all object creates are done well except for 
the last one using a sub or method returning the created object.



class X {
  has Str $.a;
}

my X $x .= new(a => 'abc');
say "\$x = {$x.perl}";

$x .= new(:a('abc'));
say "\$x = {$x.perl}";

$x .= new :a('abc');
say "\$x = {$x.perl}";

$x .= new :a;
say "\$x = {$x.perl}";

class X::Y {
  has Str $.a;
  has Str $.b;
}

my  $y = X::Y.new(
  a => 'abc',
  b => 'def'
);
say "\$y = {$y.perl}";

$y .= new( :a('abc'), :b('def'));
say "\$y = {$y.perl}";

$y .= new :a('abc') :b('def');
say "\$y = {$y.perl}";

$y .= new :a :b;
say "\$y = {$y.perl}";



my X::Y $z = xy( );
say "\$z = {$z.perl}";

sub xy ( Str $s1, Str $s2 --> X::Y ) {
  return X::Y.new(
a => 'abc',
b => 'def'
  );
}


The output and error returned is

$x = X.new(a => "abc")
$x = X.new(a => "abc")
$x = X.new(a => "abc")
$x = X.new(a => "abc")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
$y = X::Y.new(a => "abc", b => "def")
Too few positionals passed; expected 2 arguments but got 1
  in sub xy at named-parameters.pl6:46
  in block  at named-parameters.pl6:43


I have to explicitly rewrite it into one of the colon forms (';')

my  $y = X::Y.new(
  :a('abc'),
  :b('def')
);

Greets,
M

[perl #123037] [BUG] Typed array contains (Any) type objects when assigning past the end of the array in Rakudo

[Christian Bartolomaeus via RT]

On Thu Oct 23 04:51:47 2014, masak wrote:
>  m: my Int @a; @a[4]++; say @a[0]; say @a
>  rakudo-moar 315ec6: OUTPUT«(Int)␤(Any) (Any) (Any) (Any) 1␤»
>  Is that *supposed* to say "(Any)" there?
>  no, (Int)
> * masak submits rakudobug

Actually, the typed array seems to contain (Int) type objects -- as the output 
of @a[0] also shows:

$ perl6 -e 'my Int @a; @a[4]++; say @a[0]; say @a.perl'
(Int)
Array[Int].new(Int, Int, Int, Int, 1)

The problem seems to be in .gist (which is called with 'say @a' in the first 
evaluation). More specifically, .gist calls .map on @a and the type info is not 
present within .map. (Also reported in 
https://rt.perl.org/Ticket/Display.html?id=120071).

$ perl6 -e 'my Int @a; @a[4]++; @a.map:{say .WHAT.perl};'
Any
Any
Any
Any
Int

I'm going to change the subject of this ticket and add a reference to RT 
#120071.

[perl #125998] Should IO objects behave like values?

[via RT]

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


This::

   '/tmp'.IO eqv '/tmp'.IO

returns ``False``.

Is this correct? Should IO behave like value objects?

Possible problems:

- two IO referring to non-existent paths: should they compare like
  their string representation? or always be different? or what?
- ``/tmp`` and ``/tmp/``: should they compare as equal? should we
  ``.resolve`` them before comparing?

-- 
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

Every journalist has a novel in him, which is an excellent place for it.

Re: [perl #125998] Should IO objects behave like values?

[Bart Wiegmans]

I kind of think that's impossibly complex. What does it even mean for IO
objects to be value-equal? They represent unknowns in any case. Even if
they resolved to the same file, they might be read at different times and
have different contents. Or a write to one object may succeed and another
may not.
No, I don't think IO should be a value object.

Bart

2015-09-05 16:14 GMT+02:00 Elizabeth Mattijsen <l...@dijkmat.nl>:

> > On 05 Sep 2015, at 16:06, dakkar (via RT) <perl6-bugs-follo...@perl.org>
> wrote:
> >
> > # New Ticket Created by  dakkar
> > # Please include the string:  [perl #125998]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=125998 >
> >
> >
> > This::
> >
> >   '/tmp'.IO eqv '/tmp'.IO
> >
> > returns ``False``.
> >
> > Is this correct? Should IO behave like value objects?
> >
> > Possible problems:
> >
> > - two IO referring to non-existent paths: should they compare like
> >  their string representation? or always be different? or what?
> > - ``/tmp`` and ``/tmp/``: should they compare as equal? should we
> >  ``.resolve`` them before comparing?
>
> If they should work as value objects, they should probably compare
> .abspath.
>
>
>
> Liz

Re: [perl #125998] Should IO objects behave like values?

[Elizabeth Mattijsen]

Note that we’re talking really about IO::Path objects here, which is what .IO 
generates.

And in that context, I think an object $a with a given abspath, would be eqv to 
$b with the same abspath.  Because that *is* the identifier on a file system, 
is it not?



Liz
=
> On 05 Sep 2015, at 17:03, Bart Wiegmans <bartwiegm...@gmail.com> wrote:
> 
> I kind of think that's impossibly complex. What does it even mean for IO 
> objects to be value-equal? They represent unknowns in any case. Even if they 
> resolved to the same file, they might be read at different times and have 
> different contents. Or a write to one object may succeed and another may not.
> No, I don't think IO should be a value object.
> 
> Bart
> 
> 2015-09-05 16:14 GMT+02:00 Elizabeth Mattijsen <l...@dijkmat.nl>:
> > On 05 Sep 2015, at 16:06, dakkar (via RT) <perl6-bugs-follo...@perl.org> 
> > wrote:
> >
> > # New Ticket Created by  dakkar
> > # Please include the string:  [perl #125998]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=125998 >
> >
> >
> > This::
> >
> >   '/tmp'.IO eqv '/tmp'.IO
> >
> > returns ``False``.
> >
> > Is this correct? Should IO behave like value objects?
> >
> > Possible problems:
> >
> > - two IO referring to non-existent paths: should they compare like
> >  their string representation? or always be different? or what?
> > - ``/tmp`` and ``/tmp/``: should they compare as equal? should we
> >  ``.resolve`` them before comparing?
> 
> If they should work as value objects, they should probably compare .abspath.
> 
> 
> 
> Liz
> 

Re: [perl #125998] Should IO objects behave like values?

[Elizabeth Mattijsen]

> On 05 Sep 2015, at 16:06, dakkar (via RT) <perl6-bugs-follo...@perl.org> 
> wrote:
> 
> # New Ticket Created by  dakkar 
> # Please include the string:  [perl #125998]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=125998 >
> 
> 
> This::
> 
>   '/tmp'.IO eqv '/tmp'.IO
> 
> returns ``False``.
> 
> Is this correct? Should IO behave like value objects?
> 
> Possible problems:
> 
> - two IO referring to non-existent paths: should they compare like
>  their string representation? or always be different? or what?
> - ``/tmp`` and ``/tmp/``: should they compare as equal? should we
>  ``.resolve`` them before comparing?

If they should work as value objects, they should probably compare .abspath.



Liz

[perl #125655] Garbage collected running Proc::Async objects don't seem to clean up their handles, causing libuv to abort()

[via RT]

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


See the attached script.

This is similar to https://rt.perl.org/Ticket/Display.html?id=125654use v6;
use nqp;

for ^1000 {
.say;

my $proc = Proc::Async.new('sleep', '20', :w);
$proc.stdout.tap(- $ {});
$proc.start;

nqp::force_gc();
}

say 'done';

[perl #125656] Creating too many Proc::Async objects fills the file descriptor table, which causes libuv to abort()

[via RT]

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


See the attached script.use v6;

my @procs;

for ^1000 {
.say;

my $proc = Proc::Async.new('sleep', '20', :w);
$proc.stdout.tap(- $ {});
$proc.start;

@procs.push: $proc;
}

say 'done';

[perl6/specs] beb870: Spec action objects/methods

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: beb870dbff3460b981055034ee5b6e72307b7d34
  
https://github.com/perl6/specs/commit/beb870dbff3460b981055034ee5b6e72307b7d34
  Author: Rob Hoelz r...@hoelz.ro
  Date:   2015-07-04 (Sat, 04 Jul 2015)

  Changed paths:
M S05-regex.pod

  Log Message:
  ---
  Spec action objects/methods


  Commit: e4f79178aa87db3fd51ca50eeb38451c86cc7b42
  
https://github.com/perl6/specs/commit/e4f79178aa87db3fd51ca50eeb38451c86cc7b42
  Author: Rob Hoelz r...@hoelz.ro
  Date:   2015-07-04 (Sat, 04 Jul 2015)

  Changed paths:
M S99-glossary.pod

  Log Message:
  ---
  Link to action objects section in glossary


Compare: https://github.com/perl6/specs/compare/ace089e004fe...e4f79178aa87

[perl #112660] [BUG] Can push non-X objects to an attribute array typed with X in Rakudo

[Christian Bartolomaeus via RT]

AFAIU this ticket is about the type of @.slots not being respected. This seems 
to be fixed now:

$ perl6 -e 'class A { has Method @.slots; }; A.new.slots.push: [1, 2, 3]'
Type check failed in assignment to '@!slots'; expected 'Method' but got 'Array'
  in block unit at -e:1

I added a test to S32-array/push.t with commit 
https://github.com/perl6/roast/commit/d466fc79bb.

I'm closing this ticket as 'resolved'.

[perl #125293] Match objects don't roundtrip through .perl

[Christian Bartolomaeus via RT]

As far as I understand it, the problem can be golfed to the following:

$ perl6 -e 'say EnumMap.new(a, 42).perl'
EnumMap.new(:a(42))

$ perl6 -e 'say EnumMap.new(a, 42).perl.perl'
EnumMap.new(:a(42))

$ perl6 -e 'say EnumMap.new(a, 42).perl.EVAL'
EnumMap.new()

[perl #125293] Match objects don't roundtrip through .perl

[Will Coleda via RT]

Additionally, there's a test that refers to operator on the match object, 
which dies with:

This representation (Null) does not support associative access
  in block unit at t/spec/S05-match/perl.rakudo.moar:23

That is skipped.

--
Will Coke Coleda

[perl #125293] Match objects don't roundtrip through .perl

[via RT]

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


There's a failing test in S05-match/perl.t for this.

Looks like the topmost hash attribute isn't the same.

# expected: Match.new(ast = Any, list = (), hash =
EnumMap.new(:operator([Match.new(ast = Any, list = (), hash =
EnumMap.new(), orig = 2 + 4, to = 3, from = 2)])), orig = 2 +
4, to = 5, from = 0)
#  got: Match.new(ast = Any, list = (), hash = EnumMap.new(),
orig = 2 + 4, to = 5, from = 0)

-- 
Will Coke Coleda

[perl #124226] [BUG] Opportunity to catch syntactically detectable calls to attribute-accessing methods on type objects in Rakudo

[Carl Mäsak]

# New Ticket Created by  Carl Mäsak 
# Please include the string:  [perl #124226]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/Ticket/Display.html?id=124226 


[Tux] m: class C { has Int $!x; method foo { ($!x, my $b) = (1,2);}};C.foo
19:45 +camelia rakudo-moar 6caf1d: OUTPUT«Cannot look up attributes
in a type object␤  in method foo [...]
[Tux] is that explainable?
masak you're calling C.foo, the .foo method on the type object C
masak the type object doesn't really properly have an $!x
masak m: class C { has Int $!x; method foo { ($!x, my $b) =
(1,2);}}; C.new.foo
camelia rakudo-moar 6caf1d: ( no output )
masak that works.
TimToady Cannot look up attributes in a type object is an
implementor-centric error message, not a user-centric one
Juerd TimToady: Instance attribute used in non-instance method call? :)
masak TimToady: actually, that error message could fail statically
in this case.
masak since C is already resolved at compile time.
masak no need to make it survive until runtime and then fail.
[...]
masak no-one else liked the idea of statically erroring out with
call will never work for the C.foo case where C is already
statically resolved?
nine_ masak: I do
Juerd masak: Could work, but can't methods be marked as instance-only?
nine_ masak: the earlier errors are reported the better
PerlJam masak: How does the compiler decide that it will never work? and when?
Juerd Because then, any use of $!foo could simply mark the method as
instance-only
Juerd And the error message could be simpler.
Juerd Method foo can only be called on an instance of C, not on C itself.
PerlJam (compiler hints)++ if we can reasonably have them.
PerlJam I guess, if you declare the sig right, all the info is easy
to get at.  But without that, it seems like a bit of guessing for the
compiler to do it.
masak PerlJam: compiler sees the call C.foo, and has already set a
flag that the foo method in class C accesses an attribute. boom.
* masak submits rakudobug
Juerd Method foo can only be called on an instance of C, not on C
itself, because C.foo accesses instance attribute $!x.
masak neat. +1
PerlJam masak: flagging methods like that seems like quite a bit of
bookkeeping for marginal benefit.
masak really? seems worth it to me...
masak it's a small hash somewhere in the compiler.
masak %accattrC.foo = True;
Juerd It could be a boolean flag (instance-only) and an array of
further explanations
[Coke] masak: I think you mean a compile-time static check, not a
static static check. ;)
masak [Coke]: yes. thank you. I meant... that, what you said.

[perl #123702] Race when creating buf8 objects (involving typed roles?)

[via RT]

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





'await do for 1..5 { start { buf8.new } }' results in error 50+% of the time on 
my machine (perl6-m). 
https://github.com/retupmoca/rakudo/commit/d2eba029e90d89b48085b800118251deb578f43b
 seems to fix the issue, but I don't know if it's a good idea or what other 
implications that change would have; or even if that's the best way to 
implement the fix.

[perl #117681] .WHAT.perl on objects with a curried rule doesn't show type

[Christian Bartolomaeus via RT]

This works now as expected:

$ perl6 -e 'role Cup[::Contents] { }; class EggNog { }; my Cup of EggNog $mug; 
$mug.WHAT.perl.say'
Cup[EggNog]

Since the test in integration/advent2009-day18.t is unfudged and runs fine in 
spectests, I'm closing this ticket.