Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

[Lloyd Fournier via RT]

When I filed this ticket I kinda expected that somehow rakudo or libuv
would handle this for me under the hood. But what Timo and Brandon say
makes sense. The process is still running when you slurp-rest. slurp-rest
neds EOF before it stops blocking. It will never get it because the writing
process is keeping itself alive until it can finish writing to ERR. But it
will never finish because it's still needs to write the 8193rd byte.

Consider:

$ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); say $proc.out.get'
win

Using .get instead of slurp-rest works fine. This suggested to me that
waiting for the process to finish before .slurp-rest would work. And it did

perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); $proc.exitcode; say
$proc.out.slurp-rest'
win

But for some reason, just sleeping didn't:

perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); sleep 1; say $proc.out.slurp-rest'  #
hangs forever

I'd say this is closable. The solution is to wait for the process to exit
before reading or to use Proc::Async.

Thanks!

On Thu, Mar 8, 2018 at 2:51 PM Brandon Allbery via RT <
perl6-bugs-follo...@perl.org> wrote:

> And in the cases where it "works", the buffer is larger. Which runs the
> risk of consuming all available memory in the worst case, if someone tries
> to "make it work" with an expanding buffer. The fundamental deadlock
> between processes blocked on I/O is not solved by buffering. Something
> needs to actually consume data instead of blocking, to break the deadlock.
>
> Perl 5 and Python both call this the open3 problem.
>
> On Wed, Mar 7, 2018 at 6:42 PM, Timo Paulssen  wrote:
>
> > This is a well-known problem in IPC. If you don't do it async, you risk
> > the buffer you're not currently reading from filling up completely. Now
> > your client program is trying to write to stderr, but can't because it's
> > full. Your parent program is hoping to read from stdin, but nothing is
> > arriving, and it never reads from stderr, so it's a deadlock.
> >
> > Wouldn't call this a rakudo bug.
> >
> >
> > On 07/03/18 23:04, Christian Bartolomaeus via RT wrote:
> > > On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote:
> > >> FWIW that hangs on FreeBSD as well (maybe not too much a surprise,
> > >> given the relationship of the OSes).
> > > Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on
> > my machine:
> > >
> > > $ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*ERR.print("8" x
> > 224001);|,:out,:err); say $proc.out.slurp'   ## hangs
> > > ^C
> > > $ perl6 --version
> > > This is Rakudo Star version 2017.10 built on MoarVM version 2017.10
> > > implementing Perl 6.c.
> > > $ uname -a
> > > Linux p6 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux
> >
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>

Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever

[Lloyd Fournier]

When I filed this ticket I kinda expected that somehow rakudo or libuv
would handle this for me under the hood. But what Timo and Brandon say
makes sense. The process is still running when you slurp-rest. slurp-rest
neds EOF before it stops blocking. It will never get it because the writing
process is keeping itself alive until it can finish writing to ERR. But it
will never finish because it's still needs to write the 8193rd byte.

Consider:

$ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); say $proc.out.get'
win

Using .get instead of slurp-rest works fine. This suggested to me that
waiting for the process to finish before .slurp-rest would work. And it did

perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); $proc.exitcode; say
$proc.out.slurp-rest'
win

But for some reason, just sleeping didn't:

perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*OUT.print("win\n");
$*ERR.print("8" x 8193);|,:out,:err); sleep 1; say $proc.out.slurp-rest'  #
hangs forever

I'd say this is closable. The solution is to wait for the process to exit
before reading or to use Proc::Async.

Thanks!

On Thu, Mar 8, 2018 at 2:51 PM Brandon Allbery via RT <
perl6-bugs-follo...@perl.org> wrote:

> And in the cases where it "works", the buffer is larger. Which runs the
> risk of consuming all available memory in the worst case, if someone tries
> to "make it work" with an expanding buffer. The fundamental deadlock
> between processes blocked on I/O is not solved by buffering. Something
> needs to actually consume data instead of blocking, to break the deadlock.
>
> Perl 5 and Python both call this the open3 problem.
>
> On Wed, Mar 7, 2018 at 6:42 PM, Timo Paulssen  wrote:
>
> > This is a well-known problem in IPC. If you don't do it async, you risk
> > the buffer you're not currently reading from filling up completely. Now
> > your client program is trying to write to stderr, but can't because it's
> > full. Your parent program is hoping to read from stdin, but nothing is
> > arriving, and it never reads from stderr, so it's a deadlock.
> >
> > Wouldn't call this a rakudo bug.
> >
> >
> > On 07/03/18 23:04, Christian Bartolomaeus via RT wrote:
> > > On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote:
> > >> FWIW that hangs on FreeBSD as well (maybe not too much a surprise,
> > >> given the relationship of the OSes).
> > > Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on
> > my machine:
> > >
> > > $ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*ERR.print("8" x
> > 224001);|,:out,:err); say $proc.out.slurp'   ## hangs
> > > ^C
> > > $ perl6 --version
> > > This is Rakudo Star version 2017.10 built on MoarVM version 2017.10
> > > implementing Perl 6.c.
> > > $ uname -a
> > > Linux p6 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux
> >
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

[Lloyd Fournier via RT]

Changing uncomposed type objects to Nil for the specific case of .ast/.made
is definitely incorrect IMO.

It happens for the exact reason lizmat said in her commit: "Wish there was
a better way to test for NQPMu
though, as this will prevent type objects being properly propagated"

Although it looks like this has been fixed for composed type objects in a
following patch. It now looks like:

method ast()  { nqp::if(nqp::istype($!made, Mu),$!made,Nil) }

But since uncomposed type objects don't inherit from Mu we have the bug.

On Tue, Nov 28, 2017 at 3:26 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> OK, the change from True to False happened here: (2017-08-21)
>
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I'm not entirely convinced that the current behavior is incorrect, but then
> again I'm sleep deprived. Maybe someone else will have a better idea.
>
> On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> > Good point. Here "No such method 'gist' for invocant of type 'Foo'
> > in block  at /tmp/aR11azfzlJ line 1" is the right one.
> >
> > This will give True/False indicating correct/incorrect:
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { $/.make($new_type) } /;
> > my $m = "a" ~~ $r;
> > note $m.ast.^name eq "Foo";
> >
> > Thanks for bisecting magic!
> >
> > On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > What do you mean exactly by “used to work”? Here's the output on all
> > > 6c
> > > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> > >
> > > Which behavior is right? Or what's would be the right snippet to
> > > reproduce
> > > it?
> > >
> > > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > > play.html?id=132085
> > > >
> > > > It turns out to be a regression.
> > > >
> > > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > > my $r = / . { make $new_type } /;
> > > > my $m = "a" ~~ $r;
> > > > note $m.ast; #-> Nil
> > > >
> > > > making an uncomposed type somehow results in Nil now. It used to
> > > > work. In
> > > > my compiler I can't really get around needing this to work.
> > > >
> > > > LL
> > >
> > >
>
>

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

[Lloyd Fournier]

Changing uncomposed type objects to Nil for the specific case of .ast/.made
is definitely incorrect IMO.

It happens for the exact reason lizmat said in her commit: "Wish there was
a better way to test for NQPMu
though, as this will prevent type objects being properly propagated"

Although it looks like this has been fixed for composed type objects in a
following patch. It now looks like:

method ast()  { nqp::if(nqp::istype($!made, Mu),$!made,Nil) }

But since uncomposed type objects don't inherit from Mu we have the bug.

On Tue, Nov 28, 2017 at 3:26 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> OK, the change from True to False happened here: (2017-08-21)
>
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I'm not entirely convinced that the current behavior is incorrect, but then
> again I'm sleep deprived. Maybe someone else will have a better idea.
>
> On 2017-11-27 19:00:45, lloyd.fo...@gmail.com wrote:
> > Good point. Here "No such method 'gist' for invocant of type 'Foo'
> > in block  at /tmp/aR11azfzlJ line 1" is the right one.
> >
> > This will give True/False indicating correct/incorrect:
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { $/.make($new_type) } /;
> > my $m = "a" ~~ $r;
> > note $m.ast.^name eq "Foo";
> >
> > Thanks for bisecting magic!
> >
> > On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > What do you mean exactly by “used to work”? Here's the output on all
> > > 6c
> > > releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
> > >
> > > Which behavior is right? Or what's would be the right snippet to
> > > reproduce
> > > it?
> > >
> > > On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > > > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > > > play.html?id=132085
> > > >
> > > > It turns out to be a regression.
> > > >
> > > > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > > > my $r = / . { make $new_type } /;
> > > > my $m = "a" ~~ $r;
> > > > note $m.ast; #-> Nil
> > > >
> > > > making an uncomposed type somehow results in Nil now. It used to
> > > > work. In
> > > > my compiler I can't really get around needing this to work.
> > > >
> > > > LL
> > >
> > >
>
>

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

[Lloyd Fournier via RT]

Good point. Here "No such method 'gist' for invocant of type 'Foo'
  in block  at /tmp/aR11azfzlJ line 1" is the right one.

This will give True/False indicating correct/incorrect:

my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { $/.make($new_type) } /;
my $m = "a" ~~ $r;
note $m.ast.^name eq "Foo";

Thanks for bisecting magic!

On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> What do you mean exactly by “used to work”? Here's the output on all 6c
> releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
>
> Which behavior is right? Or what's would be the right snippet to reproduce
> it?
>
> On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > play.html?id=132085
> >
> > It turns out to be a regression.
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { make $new_type } /;
> > my $m = "a" ~~ $r;
> > note $m.ast; #-> Nil
> >
> > making an uncomposed type somehow results in Nil now. It used to work. In
> > my compiler I can't really get around needing this to work.
> >
> > LL
>
>

Re: [perl #132512] [REGRESSION] make in regex on uncomposed type results in Nil

[Lloyd Fournier]

Good point. Here "No such method 'gist' for invocant of type 'Foo'
  in block  at /tmp/aR11azfzlJ line 1" is the right one.

This will give True/False indicating correct/incorrect:

my $new_type := Metamodel::ClassHOW.new_type(:name);
my $r = / . { $/.make($new_type) } /;
my $m = "a" ~~ $r;
note $m.ast.^name eq "Foo";

Thanks for bisecting magic!

On Tue, Nov 28, 2017 at 1:54 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> What do you mean exactly by “used to work”? Here's the output on all 6c
> releases: https://gist.github.com/efee7716c35d36c6f793465c2f0b6035
>
> Which behavior is right? Or what's would be the right snippet to reproduce
> it?
>
> On 2017-11-27 18:48:07, lloyd.fo...@gmail.com wrote:
> > Just got around to investigating: https://rt.perl.org/Ticket/Dis
> > play.html?id=132085
> >
> > It turns out to be a regression.
> >
> > my $new_type := Metamodel::ClassHOW.new_type(:name);
> > my $r = / . { make $new_type } /;
> > my $m = "a" ~~ $r;
> > note $m.ast; #-> Nil
> >
> > making an uncomposed type somehow results in Nil now. It used to work. In
> > my compiler I can't really get around needing this to work.
> >
> > LL
>
>

Re: [perl #127020] [PERF] pod parsing memory is never freed

[Lloyd Fournier via RT]

Probably one of a number of things that would be easy if we made pod
another language on the braid :)

On Mon, Nov 27, 2017 at 11:59 AM Timo Paulssen via RT <
perl6-bugs-follo...@perl.org> wrote:

> a look at a profile makes me suspect the problem is having
> pod_string_character match a single character at a time, causing rather
> large numbers of match objects for comparatively short strings.
>
> It's probably worthwhile to steal a piece of implementation from
> "nibbling", aka parsing strings. a very short glance points do_nibbling out
> as interesting.
>

Re: [perl #127020] [PERF] pod parsing memory is never freed

[Lloyd Fournier]

Probably one of a number of things that would be easy if we made pod
another language on the braid :)

On Mon, Nov 27, 2017 at 11:59 AM Timo Paulssen via RT <
perl6-bugs-follo...@perl.org> wrote:

> a look at a profile makes me suspect the problem is having
> pod_string_character match a single character at a time, causing rather
> large numbers of match objects for comparatively short strings.
>
> It's probably worthwhile to steal a piece of implementation from
> "nibbling", aka parsing strings. a very short glance points do_nibbling out
> as interesting.
>

Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

[Lloyd Fournier via RT]

For comparison to march on the same comp:
bash-3.2$ perl6 perf.p6
perl6-loop: 63.0037058
c-loop: 76.86853305 (0.82 times faster)
native-loop: 0.2170930 (354.08 times faster)

perl6 loops are faster. c style loops are slower. Native loops are even
faster relative to the others (for me).

We can probably close this RT. Seeing as the issue in the title has been
addressed kinda :P

LL





On Sun, Nov 19, 2017 at 1:05 PM Daniel Green via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sun, 12 Mar 2017 07:27:37 -0700, allber...@gmail.com wrote:
> > On Sun, Mar 12, 2017 at 12:48 AM, Lloyd Fournier 
> > wrote:
> >
> > > perl6-loop: 84.8739988
> > > c-loop: 67.65849241 (1.25 times faster)
> > > native-loop: 0.4981954 (135.81 times faster)
> > >
> >
> > Still quite a lot of optimization to be done on that front. WRT native
> int,
> > one of the issues is needing to track when boxing is/isn't needed,
> > otherwise nativizing can be a pessimization because of constant reboxing.
> > The optimizer isn't up to tracking boxing like that yet.
> >
>
> FWIW.
>
> $ perl6 native-int-perf.p6
> perl6-loop: 117.55178620
> c-loop: 156.7308145 (0.75 times faster)
> native-loop: 1.2542871 (124.96 times faster)
>
> $ perl6 --version
> This is Rakudo version 2017.10-211-g2f0da94c3 built on MoarVM version
> 2017.10-82-ge876f1484
>

Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

[Lloyd Fournier]

For comparison to march on the same comp:
bash-3.2$ perl6 perf.p6
perl6-loop: 63.0037058
c-loop: 76.86853305 (0.82 times faster)
native-loop: 0.2170930 (354.08 times faster)

perl6 loops are faster. c style loops are slower. Native loops are even
faster relative to the others (for me).

We can probably close this RT. Seeing as the issue in the title has been
addressed kinda :P

LL





On Sun, Nov 19, 2017 at 1:05 PM Daniel Green via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sun, 12 Mar 2017 07:27:37 -0700, allber...@gmail.com wrote:
> > On Sun, Mar 12, 2017 at 12:48 AM, Lloyd Fournier 
> > wrote:
> >
> > > perl6-loop: 84.8739988
> > > c-loop: 67.65849241 (1.25 times faster)
> > > native-loop: 0.4981954 (135.81 times faster)
> > >
> >
> > Still quite a lot of optimization to be done on that front. WRT native
> int,
> > one of the issues is needing to track when boxing is/isn't needed,
> > otherwise nativizing can be a pessimization because of constant reboxing.
> > The optimizer isn't up to tracking boxing like that yet.
> >
>
> FWIW.
>
> $ perl6 native-int-perf.p6
> perl6-loop: 117.55178620
> c-loop: 156.7308145 (0.75 times faster)
> native-loop: 1.2542871 (124.96 times faster)
>
> $ perl6 --version
> This is Rakudo version 2017.10-211-g2f0da94c3 built on MoarVM version
> 2017.10-82-ge876f1484
>

Re: [perl #132085] [REGRESSION] Possible regression after Match.(made|ast) changes

[Lloyd Fournier via RT]

I think we can close this. It's most likely an internals change because I
call nqp::setparameterizer() directly. I'll figure out what the problem is
eventually and if I can't fix it myself I'll open a more concise RT.

Cheers

LL

On Thu, Sep 14, 2017 at 1:27 PM Aleks-Daniel Jakimenko-Aleksejev <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string:  [perl #132085]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132085 >
>
>
> Spit tests are failing on HEAD (https://github.com/spitsh/spitsh).
>
> Example output from committable:
> https://gist.github.com/9f5f6ab318e16a29057748876d8af883
>
> Bisectable points at
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I don't know if it is truly a regression or if the module was relying on
> some buggy behavior. Any info is appreciated.
>

Re: [perl #132085] [REGRESSION] Possible regression after Match.(made|ast) changes

[Lloyd Fournier]

I think we can close this. It's most likely an internals change because I
call nqp::setparameterizer() directly. I'll figure out what the problem is
eventually and if I can't fix it myself I'll open a more concise RT.

Cheers

LL

On Thu, Sep 14, 2017 at 1:27 PM Aleks-Daniel Jakimenko-Aleksejev <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev
> # Please include the string:  [perl #132085]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=132085 >
>
>
> Spit tests are failing on HEAD (https://github.com/spitsh/spitsh).
>
> Example output from committable:
> https://gist.github.com/9f5f6ab318e16a29057748876d8af883
>
> Bisectable points at
> https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75
>
> I don't know if it is truly a regression or if the module was relying on
> some buggy behavior. Any info is appreciated.
>

Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant

[Lloyd Fournier via RT]

Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2

should be re-opened :)

On Tue, Jul 25, 2017 at 11:45 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:

> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
> perl6-bugs-follo...@perl.org> wrote:
>
> > # New Ticket Created by  grond...@yahoo.fr
> > # Please include the string:  [perl #127858]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=127858 >
> >
> >
> > $ cat > A.pm6
> > unit module A;
> >
> > constant @a is export = map { (1 +< $_) => 1 }, ^3;
> >
> > $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> > Cannot invoke this object
> >   in block  at /home/grondilu/A.pm6 (A) line 3
> >   in block  at -e line 1
> >
> > $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 },
> ^3;
> > }; import A; say @a[1];'
> > 2 => 1
> >
> > $ perl6 --version
> > This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> > 2016.03-84-g4afd7b6
> > implementing Perl 6.c.
> >
>

Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant

[Lloyd Fournier]

Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2

should be re-opened :)

On Tue, Jul 25, 2017 at 11:45 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:

> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
> perl6-bugs-follo...@perl.org> wrote:
>
> > # New Ticket Created by  grond...@yahoo.fr
> > # Please include the string:  [perl #127858]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=127858 >
> >
> >
> > $ cat > A.pm6
> > unit module A;
> >
> > constant @a is export = map { (1 +< $_) => 1 }, ^3;
> >
> > $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> > Cannot invoke this object
> >   in block  at /home/grondilu/A.pm6 (A) line 3
> >   in block  at -e line 1
> >
> > $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 },
> ^3;
> > }; import A; say @a[1];'
> > 2 => 1
> >
> > $ perl6 --version
> > This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> > 2016.03-84-g4afd7b6
> > implementing Perl 6.c.
> >
>

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

[Lloyd Fournier]

Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2

should be re-opened :)

On Tue, Jul 25, 2017 at 11:42 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:

> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier <
> perl6-bugs-follo...@perl.org>
> wrote:
>
> > # New Ticket Created by  Lloyd Fournier
> > # Please include the string:  [perl #131705]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131705 >
> >
> >
> > echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6
> >
> > perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
> >
> > # getlex: outer index out of range
> >
> > This is another compile time outer lexical scope bug. Note: the array is
> > superfluous, just there to avoid triggering RT #131704.
> >
>

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

[Lloyd Fournier via RT]

Fix reverted:
https://github.com/rakudo/rakudo/commit/50d38a1f368f0addb601e857232642f3a8de3aa2

should be re-opened :)

On Tue, Jul 25, 2017 at 11:42 PM Lloyd Fournier via RT <
perl6-bugs-follo...@perl.org> wrote:

> merged patch: https://github.com/rakudo/rakudo/pull/
> tests: https://github.com/perl6/roast/pull/291/files
> can be closed
>
> On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier <
> perl6-bugs-follo...@perl.org>
> wrote:
>
> > # New Ticket Created by  Lloyd Fournier
> > # Please include the string:  [perl #131705]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131705 >
> >
> >
> > echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6
> >
> > perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
> >
> > # getlex: outer index out of range
> >
> > This is another compile time outer lexical scope bug. Note: the array is
> > superfluous, just there to avoid triggering RT #131704.
> >
>

Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant

[Lloyd Fournier via RT]

merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed

On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  grond...@yahoo.fr
> # Please include the string:  [perl #127858]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127858 >
>
>
> $ cat > A.pm6
> unit module A;
>
> constant @a is export = map { (1 +< $_) => 1 }, ^3;
>
> $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> Cannot invoke this object
>   in block  at /home/grondilu/A.pm6 (A) line 3
>   in block  at -e line 1
>
> $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 }, ^3;
> }; import A; say @a[1];'
> 2 => 1
>
> $ perl6 --version
> This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> 2016.03-84-g4afd7b6
> implementing Perl 6.c.
>

Re: [perl #127858] [BUG] "Cannot invoke this object" error while importing an array constant

[Lloyd Fournier]

merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed

On Fri, Apr 8, 2016 at 7:16 PM grond...@yahoo.fr <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  grond...@yahoo.fr
> # Please include the string:  [perl #127858]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127858 >
>
>
> $ cat > A.pm6
> unit module A;
>
> constant @a is export = map { (1 +< $_) => 1 }, ^3;
>
> $ PERL6LIB=. perl6 -e 'use A; say @a[1];'
> Cannot invoke this object
>   in block  at /home/grondilu/A.pm6 (A) line 3
>   in block  at -e line 1
>
> $ perl6 -e 'module A { constant @a is export = map { (1 +< $_) => 1 }, ^3;
> }; import A; say @a[1];'
> 2 => 1
>
> $ perl6 --version
> This is Rakudo version 2016.03-88-g600eb53 built on MoarVM version
> 2016.03-84-g4afd7b6
> implementing Perl 6.c.
>

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

[Lloyd Fournier via RT]

merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed

On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier 
wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #131705]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131705 >
>
>
> echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6
>
> perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
>
> # getlex: outer index out of range
>
> This is another compile time outer lexical scope bug. Note: the array is
> superfluous, just there to avoid triggering RT #131704.
>

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

[Lloyd Fournier]

merged patch: https://github.com/rakudo/rakudo/pull/
tests: https://github.com/perl6/roast/pull/291/files
can be closed

On Wed, Jul 5, 2017 at 3:42 PM Lloyd Fournier 
wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #131705]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131705 >
>
>
> echo 'constant @foo is export  = /{ say "hello" } ./, > Foo.pm6
>
> perl6 -I. -e 'use Foo; "foo" ~~ @foo[0];
>
> # getlex: outer index out of range
>
> This is another compile time outer lexical scope bug. Note: the array is
> superfluous, just there to avoid triggering RT #131704.
>

Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Lloyd Fournier via RT]

2¢:
? doesn't imply truth it implies a question. The ? prefix asks an
expression whether it's True or False. When used as a sigil like $?FILE
it's asking the compiler about something.

‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like it's
trying to ask something a question, but I'm not sure about what.

On Sun, Jul 23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> Yes, I should have been more clear.
>
> Basically, it should work like (:foo) does, which is construct foo => True
> pair.
>
> On 2017-07-22 19:25:19, lloyd.fo...@gmail.com wrote:
> > Sorry for being think but what is
> > say (:?foo);
> > meant to do? The OP just says it should "work".
> >
> > On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > sub foo($bar!) { say $bar }; foo(42)
> > >
> > > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > > Eh. The effort required to implement the feature is much less than
> > > > having
> > > > discussions *like this*. I'll try to be quick.
> > > >
> > > > “there's large possibility of introducing some unwanted ambiguity
> > > > somewhere”
> > > >
> > > > A good thing to keep in mind indeed.
> > > >
> > > > I don't really like these discussions before actual PRs, but if we
> > > > think about
> > > > it a little bit…
> > > >
> > > >  panics if it finds :! but then fails to find
> > > > 
> > > > (
> > > >
> > >
> > >
>
> https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> > > > ), so if there is any ambiguity introduced, then it's not bigger
> > > > than
> > > > what we
> > > > have with :! already.
> > > >
> > > > I've tried ::!CLASS and it complains about private method !CLASS.
> > > >
> > > > :?foo itself says “Confused … expecting any of: colon pair”, so it
> > > > expects a
> > > > colon pair anyway.
> > > >
> > > > Maybe you have some good examples, but *so far* looks ok.
> > > >
> > > >
> > > > “complex syntax feature”
> > > >
> > > > Let's make this complex feature strangely consistent.
> > > >
> > > >
> > > > “OP came up[^1] with this idea while trying to think of more cases
> > > > to
> > > > add to
> > > > the catalog of colon uses in Rakudo”
> > > >
> > > > Why does this sound so bad? :) Does it really matter at what point
> > > > I
> > > > noticed
> > > > that the feature that I always thought was implemented actually
> > > > isn't?
> > > > I don't
> > > > use colonpairs as often, truthy or falsy, so never noticed before.
> > > >
> > > > However, even the fact that :!foo does not align vertically with
> > > > :bar
> > > > is enough
> > > > to convince me regarding the usefulness of the proposed feature.
> > > >
> > > >
> > > > “But if we follow that logic, it'd mean:”
> > > >
> > > > What I meant was that we can make it strangely consistent in a
> > > > useful
> > > > way. Then
> > > > you extrapolated it to unbelievable extents.
> > > >
> > > > Then there are examples that are totally unrelated to the ticket.
> > > > Even
> > > > ?? !! is
> > > > not in any way strangely consistent (you can't write else { } if {
> > > > }).
> > > >
> > > >
> > > > I like this definition a lot:
> > > >
> > > >  "strangely consistent" is all about using loose connections
> > > > people have
> > > > in their brains, so that a feature feels syntactically vaguely
> > > > right
> > > > for
> > > > various reasons.
> > > >
> > > >
> > > > This ticket is not about making colonpairs accept prefix operators.
> > > > It
> > > > is also
> > > > not about being able to syntactically put ? anywhere you can put !.
> > > > And let's
> > > > also not bring unrelated stuff here (like colonpairs only accepting
> > > > natural
> > > > numbers with *no sign* whatsoever). What kind of derailing kung fu
> > > > is
> > > > this
> > > > anyway?
> > > >
> > > >
> > > > On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > > > > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com
> > > > > wrote:
> > > > > > This should work:
> > > > > >
> > > > > > Code:
> > > > > > say (:?foo);
> > > > > >
> > > > > > Result:
> > > > > > ===SORRY!=== Error while compiling -e
> > > > > > Bogus statement
> > > > > > at -e:1
> > > > > > --> say (:⏏?foo);
> > > > > > expecting any of:
> > > > > > colon pair
> > > > > >
> > > > > >
> > > > > > Because these work:
> > > > > >
> > > > > > Code:
> > > > > > say (:foo);
> > > > > > say (:!foo);
> > > > > >
> > > > > > Result:
> > > > > > foo => True
> > > > > > foo => False
> > > > >
> > > > >
> > > > > -1 from me:
> > > > >
> > > > > 1) Colonpairs are ubiquitous in the language, so there's large
> > > > > possibility of introducing some unwanted ambiguity somewhere and
> > > > > it's
> > > > > hard to predict where it might occur
> > > > > 2) Colonpairs are already one of the most complex syntax feature
> > > > > of
> > > > > the language, requiring beginners to learn a wealth of syntax

Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Lloyd Fournier]

2¢:
? doesn't imply truth it implies a question. The ? prefix asks an
expression whether it's True or False. When used as a sigil like $?FILE
it's asking the compiler about something.

‘:foo’ sets foo to True. ‘:!foo’ sets it to False. ‘:?foo’ looks like it's
trying to ask something a question, but I'm not sure about what.

On Sun, Jul 23, 2017 at 12:41 PM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> Yes, I should have been more clear.
>
> Basically, it should work like (:foo) does, which is construct foo => True
> pair.
>
> On 2017-07-22 19:25:19, lloyd.fo...@gmail.com wrote:
> > Sorry for being think but what is
> > say (:?foo);
> > meant to do? The OP just says it should "work".
> >
> > On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via
> > RT <
> > perl6-bugs-follo...@perl.org> wrote:
> >
> > > sub foo($bar!) { say $bar }; foo(42)
> > >
> > > On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > > > Eh. The effort required to implement the feature is much less than
> > > > having
> > > > discussions *like this*. I'll try to be quick.
> > > >
> > > > “there's large possibility of introducing some unwanted ambiguity
> > > > somewhere”
> > > >
> > > > A good thing to keep in mind indeed.
> > > >
> > > > I don't really like these discussions before actual PRs, but if we
> > > > think about
> > > > it a little bit…
> > > >
> > > >  panics if it finds :! but then fails to find
> > > > 
> > > > (
> > > >
> > >
> > >
>
> https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> > > > ), so if there is any ambiguity introduced, then it's not bigger
> > > > than
> > > > what we
> > > > have with :! already.
> > > >
> > > > I've tried ::!CLASS and it complains about private method !CLASS.
> > > >
> > > > :?foo itself says “Confused … expecting any of: colon pair”, so it
> > > > expects a
> > > > colon pair anyway.
> > > >
> > > > Maybe you have some good examples, but *so far* looks ok.
> > > >
> > > >
> > > > “complex syntax feature”
> > > >
> > > > Let's make this complex feature strangely consistent.
> > > >
> > > >
> > > > “OP came up[^1] with this idea while trying to think of more cases
> > > > to
> > > > add to
> > > > the catalog of colon uses in Rakudo”
> > > >
> > > > Why does this sound so bad? :) Does it really matter at what point
> > > > I
> > > > noticed
> > > > that the feature that I always thought was implemented actually
> > > > isn't?
> > > > I don't
> > > > use colonpairs as often, truthy or falsy, so never noticed before.
> > > >
> > > > However, even the fact that :!foo does not align vertically with
> > > > :bar
> > > > is enough
> > > > to convince me regarding the usefulness of the proposed feature.
> > > >
> > > >
> > > > “But if we follow that logic, it'd mean:”
> > > >
> > > > What I meant was that we can make it strangely consistent in a
> > > > useful
> > > > way. Then
> > > > you extrapolated it to unbelievable extents.
> > > >
> > > > Then there are examples that are totally unrelated to the ticket.
> > > > Even
> > > > ?? !! is
> > > > not in any way strangely consistent (you can't write else { } if {
> > > > }).
> > > >
> > > >
> > > > I like this definition a lot:
> > > >
> > > >  "strangely consistent" is all about using loose connections
> > > > people have
> > > > in their brains, so that a feature feels syntactically vaguely
> > > > right
> > > > for
> > > > various reasons.
> > > >
> > > >
> > > > This ticket is not about making colonpairs accept prefix operators.
> > > > It
> > > > is also
> > > > not about being able to syntactically put ? anywhere you can put !.
> > > > And let's
> > > > also not bring unrelated stuff here (like colonpairs only accepting
> > > > natural
> > > > numbers with *no sign* whatsoever). What kind of derailing kung fu
> > > > is
> > > > this
> > > > anyway?
> > > >
> > > >
> > > > On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > > > > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com
> > > > > wrote:
> > > > > > This should work:
> > > > > >
> > > > > > Code:
> > > > > > say (:?foo);
> > > > > >
> > > > > > Result:
> > > > > > ===SORRY!=== Error while compiling -e
> > > > > > Bogus statement
> > > > > > at -e:1
> > > > > > --> say (:⏏?foo);
> > > > > > expecting any of:
> > > > > > colon pair
> > > > > >
> > > > > >
> > > > > > Because these work:
> > > > > >
> > > > > > Code:
> > > > > > say (:foo);
> > > > > > say (:!foo);
> > > > > >
> > > > > > Result:
> > > > > > foo => True
> > > > > > foo => False
> > > > >
> > > > >
> > > > > -1 from me:
> > > > >
> > > > > 1) Colonpairs are ubiquitous in the language, so there's large
> > > > > possibility of introducing some unwanted ambiguity somewhere and
> > > > > it's
> > > > > hard to predict where it might occur
> > > > > 2) Colonpairs are already one of the most complex syntax feature
> > > > > of
> > > > > the language, requiring beginners to learn a wealth of syntax

Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Lloyd Fournier]

Sorry for being think but what is
say (:?foo);
meant to do? The OP just says it should "work".

On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> sub foo($bar!) { say $bar }; foo(42)
>
> On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > Eh. The effort required to implement the feature is much less than
> > having
> > discussions *like this*. I'll try to be quick.
> >
> > “there's large possibility of introducing some unwanted ambiguity
> > somewhere”
> >
> > A good thing to keep in mind indeed.
> >
> > I don't really like these discussions before actual PRs, but if we
> > think about
> > it a little bit…
> >
> >  panics if it finds :! but then fails to find 
> > (
> >
>
> https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> > ), so if there is any ambiguity introduced, then it's not bigger than
> > what we
> > have with :! already.
> >
> > I've tried ::!CLASS and it complains about private method !CLASS.
> >
> > :?foo itself says “Confused … expecting any of: colon pair”, so it
> > expects a
> > colon pair anyway.
> >
> > Maybe you have some good examples, but *so far* looks ok.
> >
> >
> > “complex syntax feature”
> >
> > Let's make this complex feature strangely consistent.
> >
> >
> > “OP came up[^1] with this idea while trying to think of more cases to
> > add to
> > the catalog of colon uses in Rakudo”
> >
> > Why does this sound so bad? :) Does it really matter at what point I
> > noticed
> > that the feature that I always thought was implemented actually isn't?
> > I don't
> > use colonpairs as often, truthy or falsy, so never noticed before.
> >
> > However, even the fact that :!foo does not align vertically with :bar
> > is enough
> > to convince me regarding the usefulness of the proposed feature.
> >
> >
> > “But if we follow that logic, it'd mean:”
> >
> > What I meant was that we can make it strangely consistent in a useful
> > way. Then
> > you extrapolated it to unbelievable extents.
> >
> > Then there are examples that are totally unrelated to the ticket. Even
> > ?? !! is
> > not in any way strangely consistent (you can't write else { } if { }).
> >
> >
> > I like this definition a lot:
> >
> >  "strangely consistent" is all about using loose connections
> > people have
> > in their brains, so that a feature feels syntactically vaguely right
> > for
> > various reasons.
> >
> >
> > This ticket is not about making colonpairs accept prefix operators. It
> > is also
> > not about being able to syntactically put ? anywhere you can put !.
> > And let's
> > also not bring unrelated stuff here (like colonpairs only accepting
> > natural
> > numbers with *no sign* whatsoever). What kind of derailing kung fu is
> > this
> > anyway?
> >
> >
> > On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > > > This should work:
> > > >
> > > > Code:
> > > > say (:?foo);
> > > >
> > > > Result:
> > > > ===SORRY!=== Error while compiling -e
> > > > Bogus statement
> > > > at -e:1
> > > > --> say (:⏏?foo);
> > > > expecting any of:
> > > > colon pair
> > > >
> > > >
> > > > Because these work:
> > > >
> > > > Code:
> > > > say (:foo);
> > > > say (:!foo);
> > > >
> > > > Result:
> > > > foo => True
> > > > foo => False
> > >
> > >
> > > -1 from me:
> > >
> > > 1) Colonpairs are ubiquitous in the language, so there's large
> > > possibility of introducing some unwanted ambiguity somewhere and it's
> > > hard to predict where it might occur
> > > 2) Colonpairs are already one of the most complex syntax feature of
> > > the language, requiring beginners to learn a wealth of syntax to
> > > understand most of the common code.
> > > 3) Given (1) and (2), I'd expect any changes to extend their syntax
> > > to
> > > carry large benefits, however, the proposal offers literally zero
> > > practical use and the OP came up[^1] with this idea while trying to
> > > think of more cases to add to the catalog of colon uses in Rakudo.
> > > The
> > > `?` prefix op at least coerces the already-true arg to Bool (e.g.
> > > `?"foo" === True`) but in the case of the colonpair, there's nothing
> > > to coerce, so there's absolutely no point in typing the extra `?` and
> > > it's unlikely anyone would want to type it.
> > > 4) The OP makes the case that this syntax should exist solely for the
> > > sake of consistency, by interpreting the `!` in `:!foo` syntax to
> > > mean
> > > the `!` op, and there exists the `?` op. But if we follow that logic,
> > > it'd mean:
> > > *) `!! ??` should be allowed too, to mean reverse ternary
> > > *) `::!CLASS` should mean `anything but ::?CLASS`
> > > *) `has $?foo` should be an alternative to `has $!foo`
> > > *) `self?foo` should be an alternative to `self!foo`
> > > *) `:-42foo` should parse just as `:42foo` parses
> > > The point being that the current syntax is `":"` vs `":!"` not `":"`
> >

Re: [perl #131781] :?smth should construct a truthy pair (say (:?foo))

[Lloyd Fournier via RT]

Sorry for being think but what is
say (:?foo);
meant to do? The OP just says it should "work".

On Sun, Jul 23, 2017 at 6:05 AM Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> sub foo($bar!) { say $bar }; foo(42)
>
> On 2017-07-22 11:19:41, alex.jakime...@gmail.com wrote:
> > Eh. The effort required to implement the feature is much less than
> > having
> > discussions *like this*. I'll try to be quick.
> >
> > “there's large possibility of introducing some unwanted ambiguity
> > somewhere”
> >
> > A good thing to keep in mind indeed.
> >
> > I don't really like these discussions before actual PRs, but if we
> > think about
> > it a little bit…
> >
> >  panics if it finds :! but then fails to find 
> > (
> >
>
> https://github.com/rakudo/rakudo/blob/fb7ecb60f006b5738bfe7a234535e07344268b31/src/Perl6/Grammar.nqp#L1892
> > ), so if there is any ambiguity introduced, then it's not bigger than
> > what we
> > have with :! already.
> >
> > I've tried ::!CLASS and it complains about private method !CLASS.
> >
> > :?foo itself says “Confused … expecting any of: colon pair”, so it
> > expects a
> > colon pair anyway.
> >
> > Maybe you have some good examples, but *so far* looks ok.
> >
> >
> > “complex syntax feature”
> >
> > Let's make this complex feature strangely consistent.
> >
> >
> > “OP came up[^1] with this idea while trying to think of more cases to
> > add to
> > the catalog of colon uses in Rakudo”
> >
> > Why does this sound so bad? :) Does it really matter at what point I
> > noticed
> > that the feature that I always thought was implemented actually isn't?
> > I don't
> > use colonpairs as often, truthy or falsy, so never noticed before.
> >
> > However, even the fact that :!foo does not align vertically with :bar
> > is enough
> > to convince me regarding the usefulness of the proposed feature.
> >
> >
> > “But if we follow that logic, it'd mean:”
> >
> > What I meant was that we can make it strangely consistent in a useful
> > way. Then
> > you extrapolated it to unbelievable extents.
> >
> > Then there are examples that are totally unrelated to the ticket. Even
> > ?? !! is
> > not in any way strangely consistent (you can't write else { } if { }).
> >
> >
> > I like this definition a lot:
> >
> >  "strangely consistent" is all about using loose connections
> > people have
> > in their brains, so that a feature feels syntactically vaguely right
> > for
> > various reasons.
> >
> >
> > This ticket is not about making colonpairs accept prefix operators. It
> > is also
> > not about being able to syntactically put ? anywhere you can put !.
> > And let's
> > also not bring unrelated stuff here (like colonpairs only accepting
> > natural
> > numbers with *no sign* whatsoever). What kind of derailing kung fu is
> > this
> > anyway?
> >
> >
> > On 2017-07-22 09:12:31, c...@zoffix.com wrote:
> > > On Sat, 22 Jul 2017 07:53:26 -0700, alex.jakime...@gmail.com wrote:
> > > > This should work:
> > > >
> > > > Code:
> > > > say (:?foo);
> > > >
> > > > Result:
> > > > ===SORRY!=== Error while compiling -e
> > > > Bogus statement
> > > > at -e:1
> > > > --> say (:⏏?foo);
> > > > expecting any of:
> > > > colon pair
> > > >
> > > >
> > > > Because these work:
> > > >
> > > > Code:
> > > > say (:foo);
> > > > say (:!foo);
> > > >
> > > > Result:
> > > > foo => True
> > > > foo => False
> > >
> > >
> > > -1 from me:
> > >
> > > 1) Colonpairs are ubiquitous in the language, so there's large
> > > possibility of introducing some unwanted ambiguity somewhere and it's
> > > hard to predict where it might occur
> > > 2) Colonpairs are already one of the most complex syntax feature of
> > > the language, requiring beginners to learn a wealth of syntax to
> > > understand most of the common code.
> > > 3) Given (1) and (2), I'd expect any changes to extend their syntax
> > > to
> > > carry large benefits, however, the proposal offers literally zero
> > > practical use and the OP came up[^1] with this idea while trying to
> > > think of more cases to add to the catalog of colon uses in Rakudo.
> > > The
> > > `?` prefix op at least coerces the already-true arg to Bool (e.g.
> > > `?"foo" === True`) but in the case of the colonpair, there's nothing
> > > to coerce, so there's absolutely no point in typing the extra `?` and
> > > it's unlikely anyone would want to type it.
> > > 4) The OP makes the case that this syntax should exist solely for the
> > > sake of consistency, by interpreting the `!` in `:!foo` syntax to
> > > mean
> > > the `!` op, and there exists the `?` op. But if we follow that logic,
> > > it'd mean:
> > > *) `!! ??` should be allowed too, to mean reverse ternary
> > > *) `::!CLASS` should mean `anything but ::?CLASS`
> > > *) `has $?foo` should be an alternative to `has $!foo`
> > > *) `self?foo` should be an alternative to `self!foo`
> > > *) `:-42foo` should parse just as `:42foo` parses
> > > The point being that the current syntax is `":"` vs `":!"` not `":"`
> >

Re: [perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time

[Lloyd Fournier via RT]

I did an experiment a while ago and found that string concatenation in a
loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained to me
that this was expected because strings are immutable (and therefore wasn't
worth RTing):
https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228

(some encoding issue causes  Ο(n²) to have a bunch of Ãs in it)

On Fri, Jul 21, 2017 at 6:39 AM Ron Schmidt 
wrote:

> # New Ticket Created by  Ron Schmidt
> # Please include the string:  [perl #131774]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131774 >
>
>
> From IRC:
>
> https://irclog.perlgeek.de/perl6-dev/2017-07-19#i_14893012
>
> https://irclog.perlgeek.de/perl6/2017-07-20#i_14899215
>
> Code example:
>
> for (50_000, 75_000) -> $limit {my $x; my $y = "x" x 100; $x ~= $y for
> (1..$limit); say "$limit: ", now - ENTER now}
>
> Gets a MoarVM memory panic from the eval bot for 75_000 constructing a
> 7.5 Meg string.  According to valgrind 50_000 was allocating 10GB of
> memory.  At a concat count of 150_000 Perl 5 finishes in hundredths of a
> second where p6 takes around a minute and the growth in time with p6 is
> clearly worse than linear.  "blead" updates as of July 20 include some
> improvements and timotimo on IRC mentioned that he is working on others.
>

Re: [perl #131774] [PERF] Simple, if artificial, string concatenation example hogs memory and time

[Lloyd Fournier]

I did an experiment a while ago and found that string concatenation in a
loop was Ο(n²) in rakudo. I asked about it on irc and jnthn explained to me
that this was expected because strings are immutable (and therefore wasn't
worth RTing):
https://irclog.perlgeek.de/perl6/2015-12-15#i_11720228

(some encoding issue causes  Ο(n²) to have a bunch of Ãs in it)

On Fri, Jul 21, 2017 at 6:39 AM Ron Schmidt 
wrote:

> # New Ticket Created by  Ron Schmidt
> # Please include the string:  [perl #131774]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131774 >
>
>
> From IRC:
>
> https://irclog.perlgeek.de/perl6-dev/2017-07-19#i_14893012
>
> https://irclog.perlgeek.de/perl6/2017-07-20#i_14899215
>
> Code example:
>
> for (50_000, 75_000) -> $limit {my $x; my $y = "x" x 100; $x ~= $y for
> (1..$limit); say "$limit: ", now - ENTER now}
>
> Gets a MoarVM memory panic from the eval bot for 75_000 constructing a
> 7.5 Meg string.  According to valgrind 50_000 was allocating 10GB of
> memory.  At a concat count of 150_000 Perl 5 finishes in hundredths of a
> second where p6 takes around a minute and the growth in time with p6 is
> clearly worse than linear.  "blead" updates as of July 20 include some
> improvements and timotimo on IRC mentioned that he is working on others.
>

Re: [perl #131681] default values in subsignitures don't work

[Lloyd Fournier via RT]

That makes sense.

Thank you!

On Mon, Jul 3, 2017 at 8:09 PM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Fri, 30 Jun 2017 06:41:35 -0700, lloyd.fo...@gmail.com wrote:
> > sub foo( %h ( :$foo = "bar", :$baz) ) {
> > %h;
> > }
> >
> > note foo( { :baz } ); #-> {baz => True}
> >
> > If it's not an easy fix it might warrant a "not yet implemented"
> exception.
>
> It works correctly. Doing:
>
> sub foo( %h ( :$foo = "bar", :$baz) ) {
> say $foo
> }
> foo({ foo => "baz" });
> foo({ baz => 42 });
>
> Gives the output:
>
> baz
> bar
>
> So, $foo is correctly set to the default when the hash is missing that
> key. You seem to be expecting that it would modify the original hash that
> was passed in. That is (very intentionally) not the case.
>
> /jnthn
>

Re: [perl #131681] default values in subsignitures don't work

[Lloyd Fournier]

That makes sense.

Thank you!

On Mon, Jul 3, 2017 at 8:09 PM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Fri, 30 Jun 2017 06:41:35 -0700, lloyd.fo...@gmail.com wrote:
> > sub foo( %h ( :$foo = "bar", :$baz) ) {
> > %h;
> > }
> >
> > note foo( { :baz } ); #-> {baz => True}
> >
> > If it's not an easy fix it might warrant a "not yet implemented"
> exception.
>
> It works correctly. Doing:
>
> sub foo( %h ( :$foo = "bar", :$baz) ) {
> say $foo
> }
> foo({ foo => "baz" });
> foo({ baz => 42 });
>
> Gives the output:
>
> baz
> bar
>
> So, $foo is correctly set to the default when the hash is missing that
> key. You seem to be expecting that it would modify the original hash that
> was passed in. That is (very intentionally) not the case.
>
> /jnthn
>

Re: [perl #131584] [REGERSSION] EXPORTHOW SUPERSEDE/DECLARE Cannot invoke this object

[Lloyd Fournier via RT]

Ohh and now we have toast:

https://toast.perl6.party/
Which shows maybe it was: 2017.05-394-g56e71d5


On Fri, Jun 16, 2017 at 10:13 PM Lloyd Fournier <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #131584]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131584 >
>
>
> cat >A.pm6 <<'END'
> my package EXPORTHOW {
> package DECLARE {
> constant pokemon = Metamodel::ClassHOW;
> }
> package SUPERSEDE {
> constant grammar = Metamodel::ClassHOW
> }
> }
> END
> perl6 -I. -e 'use A;'
>
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
>
> This is Rakudo version 2017.05-454-g5facb26 built on MoarVM version
> 2017.05-85-g21ee1a5
> implementing Perl 6.c.
>

Re: [perl #131584] [REGERSSION] EXPORTHOW SUPERSEDE/DECLARE Cannot invoke this object

[Lloyd Fournier]

Ohh and now we have toast:

https://toast.perl6.party/
Which shows maybe it was: 2017.05-394-g56e71d5


On Fri, Jun 16, 2017 at 10:13 PM Lloyd Fournier <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #131584]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131584 >
>
>
> cat >A.pm6 <<'END'
> my package EXPORTHOW {
> package DECLARE {
> constant pokemon = Metamodel::ClassHOW;
> }
> package SUPERSEDE {
> constant grammar = Metamodel::ClassHOW
> }
> }
> END
> perl6 -I. -e 'use A;'
>
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
>
> This is Rakudo version 2017.05-454-g5facb26 built on MoarVM version
> 2017.05-85-g21ee1a5
> implementing Perl 6.c.
>

Re: [perl #131583] [BUG] Sort content of ^methods

[Lloyd Fournier via RT]

Str.^methods.sort(*.name)

Is easy enough once you know to do it :)
I don't think we should specify a particular order for the returned methods
and alphabetic sorting is kinda arbitrary. Why not sorted by class
inheritance for example?

On Fri, Jun 16, 2017 at 2:09 PM Gabor Szabo 
wrote:

> # New Ticket Created by  Gabor Szabo
> # Please include the string:  [perl #131583]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131583 >
>
>
> I think it would be better to have the list returned by ^methods
> sorted in abc order.
>

Re: [perl #131583] [BUG] Sort content of ^methods

[Lloyd Fournier]

Str.^methods.sort(*.name)

Is easy enough once you know to do it :)
I don't think we should specify a particular order for the returned methods
and alphabetic sorting is kinda arbitrary. Why not sorted by class
inheritance for example?

On Fri, Jun 16, 2017 at 2:09 PM Gabor Szabo 
wrote:

> # New Ticket Created by  Gabor Szabo
> # Please include the string:  [perl #131583]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131583 >
>
>
> I think it would be better to have the list returned by ^methods
> sorted in abc order.
>

Re: [perl #131528] [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT

[Lloyd Fournier via RT]

I think this is just another example of the compile time closures problem
since EXPORT runs at compile time in during the loading module's
compilation.

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

For an example in my own code:

https://github.com/spitsh/spitsh/blob/master/lib/Spit/Constants.pm6

I can't put that sub definition in the constant assignment because it runs
at compile time.

On Thu, Jun 8, 2017 at 2:31 AM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #131528]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131528 >
>
>
> From what I understand subs—even `only` subs—have another Sub playing the
> role of a dispatcher or whatever:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»
>
> And it seems when the sub itself, instead of this "dispatcher", is used in
> sub EXPORT in a precompiled
> module that's used by another precompiled module, some wires get crossed
> over and the sub cannot be called:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»
>
>
> $ cat Foo.pm6
> sub EXPORT {
> Map.new: '&foo' => sub foo { say 42 }
> }
>
> $ cat Bar.pm6
> use Foo;
> foo
>
> $ perl6 -I. -MFoo -e 'foo'
> 42
>
> $ perl6 -I. -MBar -e ''
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
> $
>
> Doing any of the following fixes the above bug:
>
> - adding `no precompilation` to Foo.pm6
> - adding `no precompilation` to Bar.pm6
> - instead of using the sub directly, defining it separately and using
> `&foo` as value in the Map
>

Re: [perl #131528] [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT

[Lloyd Fournier]

I think this is just another example of the compile time closures problem
since EXPORT runs at compile time in during the loading module's
compilation.

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

For an example in my own code:

https://github.com/spitsh/spitsh/blob/master/lib/Spit/Constants.pm6

I can't put that sub definition in the constant assignment because it runs
at compile time.

On Thu, Jun 8, 2017 at 2:31 AM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #131528]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=131528 >
>
>
> From what I understand subs—even `only` subs—have another Sub playing the
> role of a dispatcher or whatever:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»
>
> And it seems when the sub itself, instead of this "dispatcher", is used in
> sub EXPORT in a precompiled
> module that's used by another precompiled module, some wires get crossed
> over and the sub cannot be called:
>
> m: sub foo {}.WHERE.say; &foo.WHERE.say
> rakudo-moar dbd0f8: OUTPUT: «139686084622776␤139686084191728␤»
>
>
> $ cat Foo.pm6
> sub EXPORT {
> Map.new: '&foo' => sub foo { say 42 }
> }
>
> $ cat Bar.pm6
> use Foo;
> foo
>
> $ perl6 -I. -MFoo -e 'foo'
> 42
>
> $ perl6 -I. -MBar -e ''
> ===SORRY!===
> Cannot invoke this object (REPR: Null; VMNull)
> $
>
> Doing any of the following fixes the above bug:
>
> - adding `no precompilation` to Foo.pm6
> - adding `no precompilation` to Bar.pm6
> - instead of using the sub directly, defining it separately and using
> `&foo` as value in the Map
>

Re: [perl #131324] Inheriting from lexical classes seems borked

[Lloyd Fournier via RT]

FWIW theoretically you get at any 'my' symbol in another module through the
compunit interface by getting the CompUnit::Handle and using the '.unit'
method to get the top lexpad of the loaded module.



On Fri, May 19, 2017 at 8:20 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> To the best of my knowledge:
>
> On Thu, 18 May 2017 03:52:42 -0700, elizabeth wrote:
> > Should this work? If not, why not?
>
> No, because the symbol is lexical to the compunit. It's the same as how
> you won't be able
> to access subs or `my` constants or variables, unless you make them `our`
> or export them.
>
> > What would be the way to inherit from lexical classes in other compunits?
>
> One way would be to export them:
>
> ./A.pm6:
> my class A is export {}
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>
>
> You can also use export sub:
> ./A.pm6:
> sub EXPORT {
> Map.new: 'A' => my class A {}
> }
>
> Or (I'm unsure what the end goal here is), take a special export arg and
> only export the class if it's present:
>
> ./A.pm6:
> sub EXPORT ($secret-password?) {
> Map.new: (
> 'A' => my class A {
> } if $secret-password ~~ 42
> )
> }
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ===SORRY!=== Error while compiling /home/zoffix/CPANPRC/rakudo/B.pm6 (B)
> 'B' cannot inherit from 'A' because it is unknown.
> at /home/zoffix/CPANPRC/rakudo/B.pm6 (B):3
>
>
> Now change ./B.pm6 to:
> my class B {
> use A 42;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>

Re: [perl #131324] Inheriting from lexical classes seems borked

[Lloyd Fournier]

FWIW theoretically you get at any 'my' symbol in another module through the
compunit interface by getting the CompUnit::Handle and using the '.unit'
method to get the top lexpad of the loaded module.



On Fri, May 19, 2017 at 8:20 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> To the best of my knowledge:
>
> On Thu, 18 May 2017 03:52:42 -0700, elizabeth wrote:
> > Should this work? If not, why not?
>
> No, because the symbol is lexical to the compunit. It's the same as how
> you won't be able
> to access subs or `my` constants or variables, unless you make them `our`
> or export them.
>
> > What would be the way to inherit from lexical classes in other compunits?
>
> One way would be to export them:
>
> ./A.pm6:
> my class A is export {}
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>
>
> You can also use export sub:
> ./A.pm6:
> sub EXPORT {
> Map.new: 'A' => my class A {}
> }
>
> Or (I'm unsure what the end goal here is), take a special export arg and
> only export the class if it's present:
>
> ./A.pm6:
> sub EXPORT ($secret-password?) {
> Map.new: (
> 'A' => my class A {
> } if $secret-password ~~ 42
> )
> }
>
> ./B.pm6:
> my class B {
> use A;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ===SORRY!=== Error while compiling /home/zoffix/CPANPRC/rakudo/B.pm6 (B)
> 'B' cannot inherit from 'A' because it is unknown.
> at /home/zoffix/CPANPRC/rakudo/B.pm6 (B):3
>
>
> Now change ./B.pm6 to:
> my class B {
> use A 42;
> also is A;
> }
> say B.^mro;
>
> $ ./perl6 -I. -MB -e ''
> ((B) (A) (Any) (Mu))
>

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

[Lloyd Fournier]

Thanks for doing that experiment. Not sure why the code breaks. But yeah on
second thought it was a bad idea. If something accepts a Mu in its
signature it should probably be given a Mu even with ~~.

LL

On Sat, Apr 8, 2017 at 12:58 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Fri, 07 Apr 2017 19:09:55 -0700, lloyd.fo...@gmail.com wrote:
> > IMO any() junctions should propagate exceptions regardless of whether
> one of its other values succeeded
>
> Well, they do. The exception gets thrown. It just aborts all of the
> results. In a superimposition of multiple universes calculating $foo == 42,
> a crash in one universe crashes all of them :|
>
Would be interesting to see a Junctioned result in $! though :)
>
> > I think it's generally considered a bug anytime ~~ throws an exception
> because of invalid LHS
>
> Yes. Please report anything that explodes in smartmatch. We recentlish
> fixed Str ~~ Numeric smartmatch exploding, so actually anyone on latest
> Rakudo Star would get an explosion in `"foo" ~~ 42`
>
> > I guess bare blocks don't autothread because $_ is Mu
>
> That's correct. Only subs and methods default to Any. Variables,
> attributes, and block's params default to Mu type constraint. Asking for a
> `Mu` is a way to avoid Junctional autothreading in routines. You'll notice
> a Junction is a Mu, but unlike most Perl 6 classes, is not an Any.
>
> > thought ACCEPTS on Code would autothread but it seems it's also Mu (could
> > we change this?).
>
> Changing it breaks 5 stresstests. We also smartmatch in `when` blocks and
> `where` constraints, so the impact would be far-reaching. Making ACCEPTS
> not accept a Mu breaks this code for example; it no longer prints the
> string:
>
> $_ = 42|42; when *.so { say "there"}
>

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

[Lloyd Fournier]

The correct way to do this is any(5,"flarg") ~~ 5. ~~ is very tolerant. I
think it's generally considered a bug anytime ~~ throws an exception
because of invalid LHS. IMO any() junctions should propagate exceptions
regardless of whether one of its other values succeeded.

I tried to think of how I could use a particular comparison operator with a
junction and have it not throw exceptions but it didn't work:

any(5,"flarg") ~~ { try $_ == 5 }

I guess  bare blocks don't autothread because $_ is Mu, but I would have
thought ACCEPTS on Code would autothread but it seems it's also Mu (could
we change this?).

The best I can do is the rather hairy:

say so any(5,"flarg") ~~ -> Any $_ { try $_ == 5 }

which also throws some "useless use of" exception for some reason :\

LL
On Sat, Apr 8, 2017 at 3:28 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

And if you just give a Failure into a Junction it doesn't explode it and
propagates it:

m: say so any("flarg",42)».Numeric
rakudo-moar 15a25d: OUTPUT: «True␤»

m: say sub ($_) { .^name }( +any("flarg",42) )
rakudo-moar 15a25d: OUTPUT: «any(Failure, Int)␤»

Wonder if there's a way to make it handle exceptions too somehow. A sort of
Junctionized `try` block

Re: [perl #131106] [BUG] Code.ACCEPTS not raw enough

[Lloyd Fournier]

Tests were merged here:

https://github.com/perl6/roast/commit/c0870cab72b75bfd66580b5248d9465edc4fea04


On Thu, Apr 6, 2017 at 6:18 PM Elizabeth Mattijsen via RT <
perl6-bugs-follo...@perl.org> wrote:

> Fixed with c0eb9bd10f , tests needed
>
> > On 6 Apr 2017, at 05:48, Lloyd Fournier (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Lloyd Fournier
> > # Please include the string:  [perl #131106]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131106 >
> >
> >
> > 13:36 < llfourn> m: my $foo = "foo"; my \t = (* =:= $foo); say $foo ~~ t;
> > say t.($foo) #
> > bug?
> > 13:36 <+camelia> rakudo-moar ad01ed: OUTPUT: «False␤True␤»
>
>
>

Re: [perl #131092] [REGEX] Alternation fails matching the same token on either side

[Lloyd Fournier]

Ah woops. I thought I was testing it without grammar tracer as well. Thanks
for clearing that up for me :)

On Tue, Apr 4, 2017 at 10:27 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sun, 02 Apr 2017 19:19:11 -0700, lloyd.fo...@gmail.com wrote:
> > use Grammar::Tracer;
> > grammar G {
> > token TOP {  ||  }
> > token first-fail {  '?' }
> > token second-succeed {  '!' }
> > token thing { "foo" }
> > }
> > note G.parse("foo!")
> >
> > #grammar tracer output:
> >
> > TOP
> > |  first-fail
> > |  |  thing
> > |  |  * MATCH "foo"
> > |  * FAIL
> > |  second-succeed
> > |  |  thing
> > |  |  * MATCH "" # it actually matches it but it's an empty string...
> > |  * FAIL
> > * FAIL
> > Nil
> >
> > If you just create an identical second token and use that instead it
> works:
> >
> > grammar G {
> > token TOP {  ||  }
> > token first-fail {  '?' }
> > token second-succeed {  '!' }
> > token thing { "foo" }
> > token thing2 { "foo" }
> > }
> >
> > note G.parse("foo!")
> >
> > ｢foo!｣
> >  second-succeed => ｢foo!｣
> >   thing2 => ｢foo｣
>
>
> Moved to Grammar::Debugger's ticket queue[^1], since it matches just fine
> when the module isn't used.
> It has a related ticket about `.parse`ing twice.
>
> https://github.com/jnthn/grammar-debugger/issues/33
>

Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops

[Lloyd Fournier]

If you think that discrepancy is impressive you're going to love this. I
added a version to your example using native ints:
https://gist.github.com/LLFourn/8c3e895e789fab957355ce23c9420133

bash-3.2$ perl6 native-int-perf.p6
perl6-loop: 84.8739988
c-loop: 67.65849241 (1.25 times faster)
native-loop: 0.4981954 (135.81 times faster)

(!)

On Sun, Mar 12, 2017 at 2:08 AM Michael Schaap 
wrote:

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


Perl6-style simple a-to-b loops are often much slower than the
corresponding C-style loops, especially when dealing with embedded loops.

My "real life" example (as far as Project Euler is real life) is:
http://pastebin.com/SVYAyA5z
It takes about 55 seconds on my machine with C-style loops, and about 88
seconds with Perl6-style loops.  (Comment the "loop" statements and
uncomment the corresponding "for" statements.)

A reduced example is at the bottom of this report.  It outputs

111.04240975
95.56877319

on my machine.

I'm using the latest Rakudo Star, 2017.01.

See: https://irclog.perlgeek.de/perl6/2017-03-11#i_14245536 and below.

--

#!/usr/bin/env perl6

sub perl6-loop($n)
{
 my $start = now;
 my $sum = 0;
 for 1..$n -> $i {
 for 1..$i -> $j {
 $sum += $i+$j;
 }
 }
 say now - $start;
}

sub c-loop($n)
{
 my $start = now;
 my $sum = 0;
 loop (my $i = 1; $i <= $n; $i++) {
 loop (my $j = 1; $j <= $i; $j++) {
 $sum += $i+$j;
 }
 }
 say now - $start;
}

sub MAIN($n = 10⁴)
{
 perl6-loop($n);
 c-loop($n);
}

Re: [perl #130817] [BUG] shaped array attribute cannot be initialized from previously defined attributes

[Lloyd Fournier]

I expected this wouldn't work because the attribute definition is parsed at
compile time when $!x and $!y aren't known. The error is definitely LTA.

You can do what you want like this:

class rect {
  has $.x;
  has $.y;

  has Array $.area .= new(:shape($!x,$!y))
}

say rect.new(x => 3,y => 4).area.shape[1] #-> 4

$.area has to be a $ attribute because @ will do array assignment which
will lose the shape of the RHS array (and we are not able to do := in the
default for attributes atm).

LL


On Mon, Feb 20, 2017 at 8:19 AM Neven Luetic 
wrote:

> # New Ticket Created by  Neven Luetic
> # Please include the string:  [perl #130817]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=130817 >
>
>
>
> class rect {
>   has $.x;
>   has $.y;
>
>   has @.area[$!x;$!y];
> }
>
> my $rect = rect.new(x => 3, y => 5);
>
> gives:
> Cannot look up attributes in a VMNull type object
>   in block  at t2.p6 line 6
>
> perl6 --version
> This is Rakudo version 2017.02-29-gb9332ae built on MoarVM version 2017.02
> implementing Perl 6.c.
>

Re: [perl #130787] [BUG] Array subsignatures confused by pair elements

[Lloyd Fournier]

I don't think this isn't a bug. This is just how signature binding works:

my ($a,$b,$c) := [10,20,v => 30]
Too few positionals passed; expected 3 arguments but got 2
  in block  at -e line 1

It makes sense to me because otherwise what would this mean?

sub s(@($a,$b,:$c)) {  }

Pair elements have to become bound to named parameters in the sub-signature.

LL

On Thu, Feb 16, 2017 at 2:43 AM David Warring 
wrote:

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


Consider:

sub s(@ ($a, $b, $c)) {
note [$a,$b,$c].perl;
}
s([10,20,30]);
s([10,20,v=>30]); # dies

david@X346:~$ perl6 -v
This is Rakudo version 2017.01-207-gb51a550 built on MoarVM version
2017.01-45-g2b0739d
implementing Perl 6.c.
david@X346:~$ perl6 /tmp/tst.pl
[10, 20, 30]
Too few positionals passed; expected 3 arguments but got 2 in sub-signature
  in sub s at /tmp/tst.pl line 1
  in block  at /tmp/tst.pl line 5

Re: [perl #130709] Issue with dynamic loading of module

[Lloyd Fournier]

looks similar to: https://rt.perl.org/Public/Bug/Display.html?id=130535

require seems to be pretty broken since the lexical module thing.
Unfortunately our tests weren't good enough to pick this up ( I think it's
because it's being required dynamically outside the mainline).

LL

On Sat, Feb 4, 2017 at 4:32 PM Fields, Christopher J 
wrote:

> Ah, okay, I missed that it isn’t in the ‘require’ but in the symbol lookup
> afterwards.  Okay, I think this makes some sense (I’ll look through docs to
> see if it goes with what is mentioned there), though it is a bit
> inconsistent in behavior with the base ‘fasta' module working while the
> nested ones (‘Bio::fasta’, ‘Bio::SeqIO::fasta’) don't.
>
>
>
> On 2/3/17, 7:38 AM, "Chris Fields via RT" 
> wrote:
>
> >Thanks nine.  My suggestion is that it's at the very least a buglet, in
> that there isn't consistency with how modules are loaded (note the module
> in the base directory, 'fasta', worked).
> >
> >If the syntax stays, I also think it's worth noting this behavior in the
> docs and pointing out why it's set up this way, both of the following imply
> the 'require ::($foo)' should work, but maybe this wasn't worked out prior
> to lexical module fixes?
> >
> >https://docs.perl6.org/syntax/require
> >https://docs.perl6.org/language/packages#index-entry-%3A%3A%28%29
> >
> >On Fri, 03 Feb 2017 02:34:45 -0800, n...@detonation.org wrote:
> >> The issue can be worked around/fixed with the following patch:
> >>
> >> diff --git a/lib/Bio/SeqIO.pm6 b/lib/Bio/SeqIO.pm6
> >> index 9ee4980..710dec4 100644
> >> --- a/lib/Bio/SeqIO.pm6
> >> +++ b/lib/Bio/SeqIO.pm6
> >> @@ -10,10 +10,10 @@ class Bio::SeqIO {
> >>  require ::($format);
> >>  };
> >>
> >> -if ::($format) ~~ Failure {
> >> +if MY::{$format} ~~ Failure {
> >>  die "Can't load $format: $!";
> >>  } else {
> >> -$!plugin = ::($format).new();
> >> +$!plugin = MY::{$format}.new();
> >>  }
> >>  }
> >>  }
> >>
> >> As the symbols are imported lexically, you will find them in the
> >> lexical (MY) scope. I'm not sure if this should be considered a bug or
> >> not. I'm not familiar enough with the thoughts that went into the
> >> design. It's certainly a pitty, that ::() which is quite short became
> >> less useful and users have to use the longer MY::() instead.
> >
> >
>

Re: [perl #130535] Dynamic module loading by require in another modules has broken recently?

[Lloyd Fournier]

Confirmed. As you say, it's probably because require hasn't been updated to
the new lexical importing design like "use" has. A few of the tests
probably have to be re-written for require as well.

LL
On Wed, Jan 11, 2017 at 6:27 AM Asato Wakisaka 
wrote:

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


With recent moarvm, loading modules dynamically by require
::("Some::Module") in another module fails and throws error.
Here are sample codes to reproduce: https://github.com/skaji/Crust-issue

The sample codes above works fine in rakudo-2016.11, but throws exception
like "No such symbol 'C::B'" in recent one.

$ perl6 -version
This is Rakudo version 2016.12-239-gc405f0672 built on MoarVM version
2016.12-71-g331a6b43
implementing Perl 6.c.

And, it runs properly when the "require" is placed under main, not in the
module. (ref: https://github.com/skaji/Crust-issue/pull/1 )

It seems recent changes about lexical "use" affected?

Regards.

Asato Wakisaka (github.com/astj)

Re: [perl #130540] [BUG] || && and or cannot be "overloaded"

[Lloyd Fournier]

There is a &infix:<&&> which might be where some confusion comes from. I
guess that's there for meta operators. For example:

multi sub infix:<&&>("foo","bar") { "win" };
say "foo" && "bar" # bar
say  Z&&  # win

so it does kinda work actually just not as you might expect.

LL

On Thu, Jan 12, 2017 at 9:21 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Tue, 10 Jan 2017 17:59:05 -0800, c...@zoffix.com wrote:
> > On Tue, 10 Jan 2017 16:23:18 -0800, fernandocor...@gmail.com wrote:
> > > If I write another || operator it will continue to use the original
> > > version.
> > >
> > > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823
> > > 
> >
> > To save other readers sifting through the chan log... Even an only sub
> > doesn't take root:
> >
> >  m: sub infix:<||> ($, $) {"hi"}; say 42 || 55
> >  rakudo-moar 9a11ea: OUTPUT«42␤»
> >
> > This applies to &&, and, or, and I'd guess any shortcurcuiting
> > operator.
>
> These are special compiler forms that receive special code-gen, due to
> their shortcircuiting nature, and so do not result in sub calls. Thus
> there's no sub to override.
>

Re: [perl #130520] [RFC] Deprecate `flatmap`

[Lloyd Fournier]

I took a look through my codebase to see where I have used flatmap. Every
place I think I would prefer map({ }).flat on second look.

so +1

LL


On Fri, Jan 6, 2017 at 4:47 PM Sam S.  wrote:

> # New Ticket Created by  Sam S.
> # Please include the string:  [perl #130520]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=130520 >
>
>
> So, Perl 6 has a built-in `flatmap` routine:
>
> .flatmap({ ... })
>
> Show of hands: Who is reasonably sure, without testing it or looking
> it up, which of the following four expressions it corresponds to?
>
> .flat.map({ ... })
>
> .map({ ... }).flat
>
> .flat.map({ ... }).flat
>
> .map({ slip ... })
>
> And if Perl 6 regulars and core developers can't tell, do you think a
> typical Perl 6 newbie will guess correctly, and that code reviewers
> will notice when the wrong behavior was assumed?
>
> Note that the four behaviors are the same (or at least easy to
> confuse) for many simple cases - so it's quite possible to assume the
> wrong one even after a quick test, if one didn't test the more
> complicated inputs for which where they do differ.
>
> ---
>
> Second strike: Whoever wrote the p6doc entry
>  assumed the wrong behavior as
> well, and no one else seems to have noticed or cared. (See my initial
> report at .)
>
> Third strike: Its behavior isn't actually tested in Roast. The single
> Roast test that exists for it
> 
> merely tests that it is nodal, and doesn't distinguish between the
> four possible behaviors listed above.
>
> Fourth strike: Whereas `deepmap` and `duckmap` differ from plain `map`
> in how they iterate the input and how often they call the lambda,
> `flatmap` is the same as `map` in those regards and differs, rather,
> in how it collects the output. Users who take the naming scheme
> "deepmap, duckmap, flatmap" as an indication that these are three of a
> kind, will assume the wrong behavior for `flatmap`.
>
> ---
>
> Is all that confusion (and the needless proliferation of the Perl 6
> core setting) worth it, just to save typing a single character in a
> specific circumstance?
>
> Unless I'm missing something vital, I'd say it's hard to argue that
> the answer is "yes".
>
> I therefore suggest initiating the deprecation cycle in order to
> eventually drop of this routine from the Perl 6 language and Rakudo
> implementation.
>

Re: [perl #130533] how to export alias to module function?

[Lloyd Fournier]

Looks like a bug to me. Seems to be it bugs out if you put "is export" on a
constant decl where the RHS is a &sub.

You could do this until it's fixed:

sub foo is export { }
BEGIN EXPORT::DEFAULT::{'&foo-alias'} = &foo;

On Tue, Jan 10, 2017 at 1:21 AM Alexey Melezhik <
perl6-bugs-follo...@perl.org> wrote:

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


HI!

Probably I  I miss the syntax, but I am trying to make an alias for
exported module function and have this alias exported either.

$ cat lib/Foo.pm6
use v6;

unit module Foo;

sub foo is export { say "hi there" }


$ perl6 -Ilib  -e 'use Foo; foo()'
hi there


///

$ cat lib/Foo.pm6
use v6;

unit module Foo;

sub foo is export { say "hi there" }

constant &foo-alias = &foo;

perl6 -Ilib  -e 'use Foo; Foo::foo-alias()'
hi there

///

But last one does not compile:

use v6;

unit module Foo;

sub foo is export { say "hi there" }

constant &foo-alias is export = &foo;


$ perl6  -c lib/Foo.pm6
===SORRY!=== Error while compiling /home/melezhik/projects/tmp/lib/Foo.pm6
Can't use unknown trait 'is export' in a sub declaration.
at /home/melezhik/projects/tmp/lib/Foo.pm6:7
expecting any of:
rw raw hidden-from-backtrace hidden-from-USAGE
pure default DEPRECATED inlinable nodal
prec equiv tighter looser assoc leading_docs trailing_docs


Regards.

Alexey

Re: [perl #130099] .defined doesn't work with junctions

[Lloyd Fournier]

Thanks!

On Tue, Nov 15, 2016 at 1:28 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> Thanks for the report.
>
> Fixed in https://github.com/rakudo/rakudo/commit/189cb23e84
> Tests added in https://github.com/perl6/roast/commit/6b84580ecc
>
>
> On Mon, 14 Nov 2016 04:37:49 -0800, lloyd.fo...@gmail.com wrote:
> > < llfourn> m: say defined all(Any,"foo") # Why is this true? Shouldn't it
> > autothread?
> > <+camelia> rakudo-moar 59bb1b: OUTPUT«True␤»
> > < lizmat> llfourn: that feels like a bug
> >
> > Expected behaviour is that it should autothread and call .defined on the
> > values in the junction.
> >
> > https://irclog.perlgeek.de/perl6/2016-11-14#i_13563873
> > ^ Lizmat++ tried a quickfix but it didn't work so rakudobugging so it can
> > be addressed later.
>
>
>
>

Re: [perl #130034] A andthen B orelse C leaks some internal Block

[Lloyd Fournier]

Thanks for the update. As viki hinted at, isn't this a bug in itself
(andthen problems aside). Why does Empty as the first arg to orelse return
a block?

say (Empty orelse "foo")

-> ;; $_ is raw { #`(Block|140421623865904) ... }

Where as

say (Any orelse "foo")

returns the correct value.

On Thu, Nov 10, 2016 at 1:51 AM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Sun, 06 Nov 2016 20:25:50 -0800, lloyd.fo...@gmail.com wrote:
> > 15:18 < llfourn_> m: say (Str andthen .uc orelse "foo") # more golfed
> > 15:18 <+camelia> rakudo-moar 1c425f: OUTPUT«-> ;; $_ is raw {
> > #`(Block|81391040) ... }␤»
> > 15:23 < llfourn_>  m: say (Str andthen .uc orelse "foo")("wee")
> > 15:23 <+camelia> rakudo-moar 1c425f: OUTPUT«foo␤»
> >
> > unless I totally missed what these are meant to do a Block is not what
> > should be returned from this expression.
>
> The issue is due to `andthen` (and `notandthen`) actually returning Empty
> instead of the advertized "first undefined value" and since Empty is a
> Slip, it causes an issue with `orelse`.
>
> While the fix is trivial, it causes fallout with `with` operator and right
> now we're waiting for TimToady to chime in on how things should be done.
> IRC conversation:
> https://irclog.perlgeek.de/perl6-dev/2016-11-09#i_13539174
>
>

Re: [perl #129946] [BUG][SEGV] Segfault in GC

[Lloyd Fournier]

Looks like you've hit another one like:

https://rt.perl.org/Public/Bug/Display.html?id=128553
https://github.com/MoarVM/MoarVM/issues/412

On Mon, Oct 24, 2016 at 12:31 AM via RT 
wrote:

> # New Ticket Created by
> # Please include the string:  [perl #129946]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129946 >
>
>
> Hi,
> with Rakudo version 2016.10-37-g127b3be built on MoarVM version
> 2016.10-15-g715e39 (and --debug=3 on the MoarVM) I get a segfault with
> the backtrace at the end.
>
> This is with the tests of https://github.com/jonathanstowe/Squirrel and
> I am currently not able to replicate with a smaller example as it seems
> to do it after an unpredictable number of tests though I will continue
> to try as I'd like to get this working again (this is only fairly
> recent.)
>
> #0  0x77911487 in gc_mark (tc=0x6037d0, st=,
> data=, worklist=0x6511d40) at
> src/6model/reprs/MVMCallCapture.c:55
> ctx = 0x61c9e90
> count = 4
> i = 0
> flag = 0
> flag_map = 
> body = 
> st = 
> worklist = 0x6511d40
> data = 
> tc = 0x6037d0
> body = 
> #1  0x778e7a60 in process_worklist (tc=tc@entry=0x6037d0,
> worklist=worklist@entry=0x6511d40, wtp=wtp@entry=0x7fffd4a0,
> gen=gen@entry=0 '\000') at src/gc/collect.c:313
> item = 0x76670708
> item_gen2 = 
> to_gen2 = 1 '\001'
> gen2 = 0x603d10
> item_ptr = 
> new_addr = 0x652b520
> gen2count = 799
> #2  0x778e8191 in MVM_gc_collect (tc=0x6037d0,
> what_to_do=,
> gen=gen@entry=0 '\000') at src/gc/collect.c:129
> fromspace = 
> tospace = 
> worklist = 0x6511d40
> wtp = {num_target_threads = 0, target_work = 0x0}
> #3  0x778e42fb in run_gc (tc=tc@entry=0x6037d0,
> what_to_do=what_to_do@entry=0 '\000') at src/gc/orchestrate.c:304
> other = 
> gen = 0 '\000'
> i = 
> n = 
> #4  0x778e4c49 in MVM_gc_enter_from_allocator (tc=tc@entry=0x60
> 37d0)
> at src/gc/orchestrate.c:438
> last_starter = 0x622c90
> num_threads = 0
> #5  0x778e4e18 in MVM_gc_allocate_nursery (tc=0x6037d0,
> size=280)
> at src/gc/allocation.c:32
> allocated = 
> #6  0x778e50de in MVM_gc_allocate_frame (tc=tc@entry=0x6037d0)
> at src/gc/allocation.c:99
> f = 0x5ddf920
> #7  0x778c8df0 in MVM_frame_force_to_heap (tc=0x6037d0,
> frame=0x77fd6030)
> at src/core/frame.c:657
> promoted = 
> cur_to_promote = 0x77fd6030
> new_cur_frame = 0x0
> update_caller = 0x0
> result = 0x0
> frame = 0x77fd6030
> tc = 0x6037d0
> #8  0x778ca420 in MVM_frame_takeclosure (tc=0x6037d0,
> code=)
> at src/core/frame.c:1043
> closure = 0x74de5010
> captured = 
> #9  0x778c1d00 in MVM_interp_run (tc=tc@entry=0x6037d0,
> initial_invoke=0x5ddf920, invoke_data=0x652b538) at
> src/core/interp.c:1074
> op = 46392
> LABELS = {0x778af709 ,
>   0x778b84c0 , 0x778af8ea
> ,
>   0x778af8ea , 0x778b8165
> ,
>   0x778b819d ,
>   0x778b81b0 ,
>   0x778b81ea ,
>   0x778b8249 ,
>   0x778b8285 ,
>   0x778b82c1 ,
>   0x778b84c5 ,
>   0x778b5798 ,
>   0x778b6048 ,
>   0x778b6085 ,
>   0x778b5f02 ,
>   0x778b60c1 ,
>   0x778b5f3e ,
>   0x778b5f79 ,
>   0x778b4af1 ,
>   0x778b4b2d ,
>   0x778b4b68 ,
>   0x778b4baa ,
>   0x778b4bec ,
>   0x778b4c3a ,
>   0x778b4c9f ,
>   0x778b4cfd ,
>   0x778b927f ,
>   0x778c1e45 ,
>   0x778c1ec3 ,
>   0x778c1f3d ,
>   0x778c1faf ,
>   0x778c2028 ,
>   0x778c2095 ,
>   0x778c2105 ,
>   0x778bfebb ,
>   0x778c2701 ,
>   0x778c268d ,
>   0x778c27a2 ,
>   0x778c24bd ,
>   0x778c2531 ,
>   0x778c25ad ,
>   0x778c261d ,
>   0x778b8bfb ,
>   0x778b8c6b , 0x778af8fd
> ,
>   0x778af8fd , 0x778b8cdb
> ,
>   0x778b8f94 ,
>   0x778b8d35 ,
>   0x778b8f14 ,
>   0x778b8fea ,
>   0x778b9045 ,
>   0x778b90a1 ,
>   0x778b90fc ,
>   0x778b9157 ,
>   0x778b919b ,
>   0x778b91e7 ,
>   0x778b9233 ,
>   0x778c2251 ,
>   0x778c229d ,
>   0x778c2b91 ,
>   0x778c2bdd ,
>   0x778c2818 ,
>  

Re: [perl #127033] [CONC] threads, dynamic variables lost sometimes

[Lloyd Fournier]

Tests:
https://github.com/perl6/roast/commit/0705a6ea62a6f1cdaeb6cd46f3130d3728c4ce1b

On Tue, Oct 11, 2016 at 9:26 PM Lloyd Fournier 
wrote:

> looks like it's been fixed! \o/
>
> I will put writing test for this on my TODO.
>
>
> On Tue, Oct 11, 2016 at 5:00 AM Sam S. via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
> All the examples in this thread work fine for me, on 64bit Linux with
> current Rakudo.
>
> This is Rakudo version 2016.09-163-g92c0921 built on MoarVM version
> 2016.09-39-g688796b
> implementing Perl 6.c.
>
> Has the bug been fixed, or is it platform-dependent?
>
>

Re: [perl #127033] [CONC] threads, dynamic variables lost sometimes

[Lloyd Fournier]

looks like it's been fixed! \o/

I will put writing test for this on my TODO.


On Tue, Oct 11, 2016 at 5:00 AM Sam S. via RT 
wrote:

All the examples in this thread work fine for me, on 64bit Linux with
current Rakudo.

This is Rakudo version 2016.09-163-g92c0921 built on MoarVM version
2016.09-39-g688796b
implementing Perl 6.c.

Has the bug been fixed, or is it platform-dependent?

Re: [perl #129776] [CUR][PERF] Extremely slow performance when running in directory with lots of modules

[Lloyd Fournier]

String concat takes On2 in rakudo I think. Using join in this kind of
situation should be an improvement. (I'm commuting so can't test).
On Sat, 1 Oct 2016 at 7:11 PM, Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #129776]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129776 >
>
>
> To reproduce:
>
>  cd $(mktemp -d); git clone https://github.com/perl6/mu; touch
> Foo.pm6;
>  perl6 -I. -MFoo -e ''
>
> The perl6 command will appear to hang, although it will finish after a
> long time.
>
> The problem is due to repo ID being calculated [^1] by slurping ALL of
> the .pm6? files in the directory and subdirectories,
> concatenating all that date, and calculating sha for it.
>
> To fix the issue, and different method of coming up with the repo ID
> needs to be used.
>
> [1]
>
> https://github.com/rakudo/rakudo/blob/nom/src/core/CompUnit/Repository/FileSystem.pm#L63
>
>
>

Re: [perl #129344] [BUG] "my" variable in a recursive subroutine leaks to callers scope

[Lloyd Fournier]

Reproduced. Looks like you shouldn't nest subs inside recursive functions
atm :S.
More golfed with just $level being used to demonstrate:

sub process-list (@items, $level = 0) {
multi sub process-item ($item) {
('=' x $level) ~ $item;
}

multi sub process-item (@array) {
process-list(@array, $level + 1)
}

join "\n", map &process-item, @items;
}

my @a = 'a', 'b';
put process-list([ 9, @a, 7, 6, @a, 15, 11 ]);
-
9
=a
=b
=7
=6
==a
==b
==15
==11

^ It is never incremented/re-assigned but $level is still +1 after the call
has finished.

On Sat, Sep 24, 2016 at 8:07 AM Steve Schulze 
wrote:

> # New Ticket Created by  Steve Schulze
> # Please include the string:  [perl #129344]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129344 >
>
>
> I have a subroutine that may recurse, that contains a "my" counter
> variable. Each recursion gets its own copy of the variable, but it seems
> that when the "inner" recursion returns, the "outer" version of the
> variable gets the contents from the "inner" routine.
>
> See cut down snippet:
>
> 
>
>  sub process-list (@items, $level = 0) {
>
>  my $count = 1;  # leaks on recursion?
>
>  multi sub process-item ($item,  $level) { '' x $level ~
> $count++ ~ ') ' ~ $item }
>
>  multi sub process-item (@array, $level) { process-list(@array,
> $level + 1) }
>
>  join "\n", map { process-item($_, $level) }, @items;
>  }
>
>  my @a = 'a', 'b';
>  put process-list([ 9, @a, 7, 6, @a, 15, 11 ]);
>
> 
>
> Output:
>
> Got
>
> 1) 9
>  1) a
>  2) b
> 3) 7
> 4) 6
>  1) a
>  2) b
> 3) 15
> 4) 11
>
> Expected:
>
> 1) 9
>  1) a
>  2) b
> 2) 7
> 3) 6
>  1) a
>  2) b
> 4) 15
> 5) 11
>
>
>

Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly

[Lloyd Fournier via RT]

I think this is because .WHAT is a special case. It's not really a method
which is what you need to make *.method work. *.WHAT will always return
(Whatever) immediately.

There is an odd what of working around this:

perl6 -e 'sub foo(\a where *.&WHAT === Int ) { say "Hello"; }; foo(10); #
works

using the &WHAT sub with postfix syntax you get around the special casing.

I'm not sure if .WHAT special casing is considered a bug. I haven't been
able to find a pre-existing ticket wrt to it.

On Sat, Sep 24, 2016 at 4:42 PM Itsuki Toyota 
wrote:

> # New Ticket Created by  Itsuki Toyota
> # Please include the string:  [perl #129346]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129346 >
>
>
> See the following results
>
> $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
>   in sub foo at -e line 1
>   in block  at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
>   in sub foo at -e line 1
>   in block  at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Hello
>
> It seems that "Whatever *" cannot handle sigilless values correctly.
> I think that the 1st example should return the same result as the 3rd
> example.
>
>
>
> $ perl6 --version
> This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
> 2016.08-47-g2eedba8
> implementing Perl 6.c.
>

Re: [perl #129346] [BUG] Whatever being called on where-blocked subroutine cannot handle the sigilless values correctly

[Lloyd Fournier]

I think this is because .WHAT is a special case. It's not really a method
which is what you need to make *.method work. *.WHAT will always return
(Whatever) immediately.

There is an odd what of working around this:

perl6 -e 'sub foo(\a where *.&WHAT === Int ) { say "Hello"; }; foo(10); #
works

using the &WHAT sub with postfix syntax you get around the special casing.

I'm not sure if .WHAT special casing is considered a bug. I haven't been
able to find a pre-existing ticket wrt to it.

On Sat, Sep 24, 2016 at 4:42 PM Itsuki Toyota 
wrote:

> # New Ticket Created by  Itsuki Toyota
> # Please include the string:  [perl #129346]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129346 >
>
>
> See the following results
>
> $ perl6 -e 'sub foo(\a where { *.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
>   in sub foo at -e line 1
>   in block  at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { \e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Constraint type check failed for parameter 'a'
>   in sub foo at -e line 1
>   in block  at -e line 1
>
> $ perl6 -e 'sub foo(\a where -> \e { e.WHAT === Int } ) { say "Hello"; };
> foo(10);'
> Hello
>
> It seems that "Whatever *" cannot handle sigilless values correctly.
> I think that the 1st example should return the same result as the 3rd
> example.
>
>
>
> $ perl6 --version
> This is Rakudo version 2016.08.1-202-g78393dd built on MoarVM version
> 2016.08-47-g2eedba8
> implementing Perl 6.c.
>

Re: [perl #128846] with statement modifier doesn't return writable values

[Lloyd Fournier]

20:21 < llfourn_> m: my $a = "foo"; ($a andthen $_) = "bar"; say $a
20:21 < camelia> rakudo-moar e9409c: OUTPUT«Cannot modify an immutable Str␤
 in block  at  line 1␤␤»

andthen also has the same behaviour.

On Fri, Aug 5, 2016 at 4:53 PM Lloyd Fournier 
wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #128846]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128846 >
>
>
> my $a = "foo"; ($a if $a) = "bar"; say $a # bar
>
> my $a = "foo"; ($a with $a) = "bar"; say $a # Cannot modify an immutable
> Str
>
> my $a = "foo"; ($_ with $a) = "bar"; say $a # Cannot modify an immutable
> Str
>

Re: [perl #129263] [CONC] Outer dynamic variable not found in nested `start` block

[Lloyd Fournier]

Looks pretty similar to:
https://rt.perl.org/Public/Bug/Display.html?id=127033

On Tue, Sep 13, 2016 at 11:13 PM Elizabeth Mattijsen  wrote:

> Feels to me some kind of loop would need to be made around line 33 in
> src/core/stubs.pm, basically looping until we either find the dynamic
> variable, or look for a $*PROMISE in the context and if so, try to find it
> there?
>
> Hope this made sense, too deep in other stuff now to try things out myself.
>
> > On 13 Sep 2016, at 14:29, Sam S. (via RT) 
> wrote:
> >
> > # New Ticket Created by  Sam S.
> > # Please include the string:  [perl #129263]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=129263 >
> >
> >
> >➜  my $*a = 42;  await start { say $*a }
> >42
> >
> >➜  my $*a = 42;  await start { await start { say $*a } }
> >Dynamic variable $*foo not found
> >
> > IRC discussion (rearranged for clarity):
> >
> >  Are threads supposed to see dynamic variables declared in the
> >mainline prior to starting the thread?
> >
> > A start block will go the extra mile to make that happen
> > It just takes the CALLER:: of whatever calls Promise.start
> iirc
> >
> > But if you work directly with threads then every one has its
> >own fresh dynamic scope
> >
> >...
> >
> >  Should that still work, when it's 2 levels deep into `start`?
> >
> > Umm...I guess it'd be nice if it worked.
> > Can RT it; I don't see why we can't fix that.
>
>

Re: [perl #129220] [BUG] .list,.List, (Real,) inconsistencies

[Lloyd Fournier]

I Realised what's happening. Real is a role so calling .list on it puns it.

so the phenomenon can be boiled down to:

 Real ~~ Real.^pun # False

I'm not sure if it should be that way. I will accept notabug though :)

On Thu, Sep 8, 2016 at 12:33 AM Lloyd Fournier 
wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #129220]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129220 >
>
>
> say (Real,) ~~ Real.list;   # False
> say (Real,) ~~ Real.List;   # False
> say Real.list ~~ (Real,);   # True
> say Real.list ~~ Real.List; # True
> say Real.List ~~ (Real,);   # True
> say Real.List ~~ Real.list; # True
>
> say (Cool,) ~~ Cool.list;   # True
> say (Cool,) ~~ Cool.List;   # True
> say Cool.list ~~ (Cool,);   # True
> say Cool.list ~~ Cool.List; # True
> say Cool.List ~~ (Cool,);   # True
> say Cool.List ~~ Cool.list; # True
>
> (Real,) seems to be a special snowflake and that's not Cool.
>

Re: [perl #129143] :DEFAULT tag in "use" directive prevents import from subsequent tags

[Lloyd Fournier]

You have to have a comma after each tag. I think it will work if you do
(can't test atm). It's def LTA that there's no syntax error. Arg parsing
for use statements is LTA in general I think.

LL
On Wed, 31 Aug 2016 at 9:29 AM, Brian S. Julin 
wrote:

> # New Ticket Created by  "Brian S. Julin"
> # Please include the string:  [perl #129143]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129143 >
>
>
>
> $ cat XX.pm6
> unit module XX;
>
> our sub fee() is export { }
>
> our sub fie() is export(:tag1) { }
>
> our sub foo() is export(:tag1 :tag2) { }
>
> our sub fum() is export(:DEFAULT :tag3) { }
>
> $ PERL6LIB=. perl6 -e 'use XX; fee()'
> $ PERL6LIB=. perl6 -e 'use XX; fum()'
> $ PERL6LIB=. perl6 -e 'use XX :tag1; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :tag2; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :tag2 :DEFAULT; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :DEFAULT :tag2; foo()'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
> foo used at line 1
>
> $ PERL6LIB=. perl6 -e 'use XX :tag2 :tag1; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :tag1 :tag2; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :DEFAULT :tag3; fum()'
> $ PERL6LIB=. perl6 -e 'use XX :tag3 :DEFAULT; fum()'
> $ PERL6LIB=. perl6 -e 'use XX :tag1 :DEFAULT :tag2; foo()'
> $ PERL6LIB=. perl6 -e 'use XX :tag3 :DEFAULT :tag2; foo()'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
> foo used at line 1
>

Re: [perl #129096] [BUG] sub wrapped with mod_trait: when exported yield cryptic error message, works fine in same unit

[Lloyd Fournier]

This is another outer context lost with compile time closure bug. It's one
of the most prolific bugs in rakudo :(.

I've added this ticket to the list:

https://rt.perl.org/Public/Bug/Display.html?id=125634
https://rt.perl.org/Public/Bug/Display.html?id=126818
https://rt.perl.org/Public/Bug/Display.html?id=127034
https://rt.perl.org/Public/Bug/Display.html?id=127112
https://rt.perl.org/Public/Bug/Display.html?id=127858
https://rt.perl.org/Public/Bug/Display.html?id=127860
https://rt.perl.org/Public/Bug/Display.html?id=127959
https://rt.perl.org/Public/Bug/Display.html?id=107844
https://rt.perl.org/Public/Bug/Display.html?id=128636
https://rt.perl.org/Public/Bug/Display.html?id=129096


On Sat, 27 Aug 2016 at 10:04 AM, Eike Frost 
wrote:

> # New Ticket Created by  Eike Frost
> # Please include the string:  [perl #129096]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=129096 >
>
>
> Tested on version 2016.07.1, 2016.08.1:
>
> When executing test2.pl, the error
>
> Cannot invoke this object (REPR: Null; VMNull)
>   in block  at (...)testimport.pm (testimport) line 7
>   in any enter at gen/moar/m-Metamodel.nqp line 4012
>   in block  at test2.pl line 6
>
> is displayed. When using the same code within the same file (i.e. without
> an import of the wrapped sub), everything works as expected (i.e. output is
>
> test, successfully wrapped
> a
>
> I asked about this in #perl6. It is not 100% clear that what I am trying to
> do is supported:
>
> 12:25 < nine> ejf: well you probably mean to export the wrapped sub but
> that would mean that rakudo has to process the traits in the right way and
> I'm not sure that's guaranteed. Could be that that's just a combination of
> features
>   that's not really feasible to support.
> 12:26 < nine> ejf: could also be just a plain straight forward bug in
> rakudo :) I'm not familiar enough with that part to make a good guess and
> am too tired to start debugging right now
>
> (for reference, this also does not work if the trait_mod is part of an
> exported class or is itself marked with "is export").
>

Re: [perl #127569] [BUG] lexical packages leak into SETTING::

[Lloyd Fournier]

I was missing a ')' on the last one. Should be:

## 3 our scoped packages are not available for introspecting in
CompUnit::Handle.globalish-package;

# lib/Cool/Utils.pm
class Cool::Utils {}
class Foo { };

# main.pl
my $cu =
$*REPO.need(CompUnit::DependencySpecification.new(:short-name("Cool::Utils"));
say $cu.handle.globalish-package.WHO.keys; #-> (Foo)

^ Should be Foo and Cool::Utils

I heard that this and related issues might be solved by properly lexically
scoping packages (ie scrapping GLOBALish):

http://irclog.perlgeek.de/perl6-dev/2016-08-15#i_13026138

But I dunno the details


On Wed, Aug 24, 2016 at 4:47 AM Will Coleda via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Thu Feb 18 18:38:20 2016, lloyd.fo...@gmail.com wrote:
> > When a package already exists in an outer scope, any package declared
> > will
> > insert itself into it even if it's meant to be lexically scoped. This
> > includes the SETTING(s) (the most outer scopes). It is also
> > problematic for
> > our scoped things which manage to transcend the compunit interface's
> > encapsulation of their globalish symbols.
> >
> > This leads to a number of problems and inconsistencies. I believe it
> > will
> > be even more relevant when we try and implement jnthn++'s versioning
> > design:
> >
> > https://6guts.wordpress.com/2016/02/09/a-few-words-on-perl-6-
> > versioning-and-compatibility/
> >
> > Some examples:
> >
> > ## 1 leak out of lexical scope
> > {
> >my module Cool::Utils { }
> > }
> > say Cool::Utils;
> >
> > ## 2 runtime symbol refers to something different to compile time
> > symbol
> > with same name
> > sub leaked-into {
> >   my class Cool::Utils { method doit { "one" } }
> >   say Cool::Utils.doit; #->one
> >   say ::("Cool::Utils").doit; #->two
> > }
> >
> > {
> >   my class Cool::Utils { method doit { "two" } }
> >   leaked-into();
> > }
> >
> > ## 3 our scoped packages are not available for introspecting in
> > CompUnit::Handle.globalish-package;
> >
> > # lib/Cool/Utils.pm
> > class Cool::Utils {}
> > class Foo { };
> >
> > # main.pl
> > my $cu =
> > $*REPO.need(CompUnit::DependencySpecification.new(:short-
> > name("Cool::Utils"));
> > say $cu.handle.globalish-package.WHO.keys; #-> (Foo)
> >
> > # This was one of the things I didn't consider ( and isn't tested in
> > require.t -- will do now) which caused problems with my patch.
> > # see https://github.com/rakudo/rakudo/pull/714 ugexe's comment.
> >
> > 
> >
> > Another problem with our scoped packages inserting themselves into the
> > setting is that when we have multiple settings which one of them does
> > it
> > insert it into?
> >
> > What if a module like IO::Socket::SSL has 'use v6.c', so it never sees
> > the
> > 6.d setting. Then someone does:
> >
> > use v6.d;
> > use IO::Socket::SSL;
> >
> > If the 6.c-IO::Socket.WHO === 6.d-IO::Socket.WHO everything will be
> > fine,
> > but if not IO::Socket::SSL won't be visible to the 6.d code. It could
> > copy
> > itself to all the settings but that seems ugly to me.
> >
> > The solution could be to create a special type of package used for
> > declaring sub-packages of packages that already exist in an outer
> > scope
> > which could search it's own .WHO for the symbol before delegating to
> > the
> > outer scope package's WHO.
>
> Not all the original code still compiles; can you revisit the request with
> new examples showing the issue?
>
> --
> Will "Coke" Coleda
>

Re: [perl #128770] 5334cb725 causes erroneous sink on ($_ with "foo")

[Lloyd Fournier]

Test:
https://github.com/perl6/roast/commit/4fdee95e24998498641bc548cb4319cefd6d0a0f

On Sat, Jul 30, 2016 at 4:55 AM Larry Wall via RT <
bugs-comm...@bugs6.perl.org> wrote:

> The logical ops andthen, notandthen, and orelse were not propagating
> wantedness to their thunky args.
>
> Fixed in 7ba6dbfae97f5ff9398336e49267d51606512df9.
>
> Note that we don't generally test sink warnings currently.
>

Re: [perl #128766] Useless use of $a in sink context is spurious

[Lloyd Fournier]

test:
https://github.com/perl6/roast/commit/4fdee95e24998498641bc548cb4319cefd6d0a0f

On Sat, Jul 30, 2016 at 5:36 AM Will Coleda via RT <
bugs-comm...@bugs6.perl.org> wrote:

> Re-opening, marking testneeded.
>
> --
> Will "Coke" Coleda
>

Re: [perl #128749] [RT] Emails sent to perl6-bugs-follo...@perl.org do not replicate on RT ticket

[Lloyd Fournier]

It seems like someone has just done some cleaning of this spam queue
because responses I sent to
https://rt.perl.org/Public/Bug/Display.html?id=128553 a couple of weeks ago
just came through.

On Thu, Jul 28, 2016 at 12:03 AM Will Coleda via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Wed Jul 27 06:07:08 2016, c...@zoffix.com wrote:
> > For example, this email was sent to perl6-bugs-follo...@perl.org by
> > Zefram:
> > http://www.nntp.perl.org/group/perl.perl6.compiler/2016/07/msg13370.html
> >
> > However, it was not posted on the RT ticket:
> > https://rt.perl.org/Ticket/Display.html?id=126119
> >
> > This is extremely disruptive as the conversation on the ticket splits
> > up and the authors of replies aren't even aware their replies aren't
> > being posted to the original location.
>
> mails into RT go through a spam queue which occasionally requires human
> volunteer intervention. It's possible that it just hasn't made it through
> yet.
>
> Also, are we sure it's the followup and not the bugs-bitbucket address
> that does this? Zefram didn't reply all, he only sent his reply to the
> address with "followup" in it.
>
> --
> Will "Coke" Coleda
>

Re: [perl #128553] multi method cache causes Base64 regression

[Lloyd Fournier via RT]

I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.

(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x0009)
Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
(x86_64)
Process 75691 stopped
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
   52  MVMuint16  count = ctx->arg_count;
   53  MVMuint16  i, flag;
   54  for (i = 0, flag = 0; i < count; i++, flag++) {
-> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
   56  /* Current position is name, then next is value. */
   57  MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
   58  i++;
(lldb) bt
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
  * frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
frame #1: 0x00010003f002
libmoar.dylib`MVM_gc_mark_collectable(tc=,
worklist=, new_addr=) + 1714 at collect.c:399
frame #2: 0x00010003e883
libmoar.dylib`process_worklist(tc=0x000100500290,
worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
collect.c:313
frame #3: 0x00010003e324
libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
what_to_do=, gen=) + 820 at collect.c:129
frame #4: 0x00010003b703
libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
orchestrate.c:304
frame #5: 0x00010003b4c8
libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
orchestrate.c:438
frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate_nursery(tc=, size=) +
52 at allocation.c:32
frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
frame #8: 0x00010003bc5d
libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
at allocation.c:49
frame #9: 0x00010003bf44
libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
st=) + 84 at allocation.c:86
frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
st=) + 15 at P6opaque.c:60
frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
reprconv.c:13
frame #12: 0x000100050d19
libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
type=0x000101626fc0, val=) + 73 at reprconv.c:586
frame #13: 0x00019c07
libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
ex_obj=) +  at exceptions.c:407
frame #14: 0x000100017488
libmoar.dylib`MVM_interp_run(tc=0x000100500290,
initial_invoke=, invoke_data=) + 47320 at
interp.c:3830
frame #15: 0x0001000c8305
libmoar.dylib`MVM_vm_run_file(instance=,
filename=) + 181 at moar.c:304
frame #16: 0x0001170a moar`main(argc=,
argv=0x7fff5fbff8e8) + 666 at main.c:191
frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
(lldb) fr v
(MVMThreadContext *) tc = 0x000100500290
(MVMSTable *) st = 0x000101004f40
(void *) data = 

(MVMGCWorklist *) worklist = 0x00010d27c1a0
(MVMCallCaptureBody *) body = 

(MVMArgProcContext *) ctx = 0x00010a6f3c00
(MVMuint16) flag = 0
(MVMuint16) i = 0
(MVMuint16) count = 

(MVMuint8 *) flag_map = 0x10a72533 ""
(lldb) p flag_map
(MVMuint8 *) $6 = 0x10a72533 ""
(lldb) p flag_map[0]
error: Couldn't apply expression side effects : Couldn't dematerialize a
result variable: couldn't read its memory

On Sun, Jul 10, 2016 at 12:19 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> > Note that the final decode-base64 candidate shows the correct results
> > when debugging statements are added
> >
> > This gist also shows a small change that makes it produce the correct
> > values but it still segfaults more often than not
> > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d
>
> Having dug into it a little, I'm not sure that the new multi-caching stuff
> has caused this, so much as uncovered it (perhaps by moving GC colle

Re: [perl #128553] multi method cache causes Base64 regression

[Lloyd Fournier via RT]

By flag_map I mean ctx->callsite->arg_flags:

(lldb) p ctx->arg_flags
(MVMCallsiteEntry *) $8 = 0x
(lldb) p ctx->callsite->arg_flags
(MVMCallsiteEntry *) $9 = 0x10a72533 ""

On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier 
wrote:

> I've been getting segfaults in this area recently. The trace is a bit
> different but I guess it's related. It seems that flag_map in gc_mark is no
> longer allocated so I get segfault.
>
> (lldb) r
> There is a running process, kill it and restart?: [Y/n] y
> Process 75673 exited with status = 9 (0x0009)
> Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
> (x86_64)
> Process 75691 stopped
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
> frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
>52  MVMuint16  count = ctx->arg_count;
>53  MVMuint16  i, flag;
>54  for (i = 0, flag = 0; i < count; i++, flag++) {
> -> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
>56  /* Current position is name, then next is value. */
>57  MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
>58  i++;
> (lldb) bt
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
>   * frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
> frame #1: 0x00010003f002
> libmoar.dylib`MVM_gc_mark_collectable(tc=,
> worklist=, new_addr=) + 1714 at collect.c:399
> frame #2: 0x00010003e883
> libmoar.dylib`process_worklist(tc=0x000100500290,
> worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
> collect.c:313
> frame #3: 0x00010003e324
> libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
> what_to_do=, gen=) + 820 at collect.c:129
> frame #4: 0x00010003b703
> libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
> orchestrate.c:304
> frame #5: 0x00010003b4c8
> libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
> orchestrate.c:438
> frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate_nursery(tc=, size=) +
> 52 at allocation.c:32
> frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
> frame #8: 0x00010003bc5d
> libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
> at allocation.c:49
> frame #9: 0x00010003bf44
> libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
> st=) + 84 at allocation.c:86
> frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
> st=) + 15 at P6opaque.c:60
> frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
> MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
> reprconv.c:13
> frame #12: 0x000100050d19
> libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
> type=0x000101626fc0, val=) + 73 at reprconv.c:586
> frame #13: 0x00019c07
> libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
> ex_obj=) +  at exceptions.c:407
> frame #14: 0x000100017488
> libmoar.dylib`MVM_interp_run(tc=0x000100500290,
> initial_invoke=, invoke_data=) + 47320 at
> interp.c:3830
> frame #15: 0x0001000c8305
> libmoar.dylib`MVM_vm_run_file(instance=,
> filename=) + 181 at moar.c:304
> frame #16: 0x0001170a moar`main(argc=,
> argv=0x7fff5fbff8e8) + 666 at main.c:191
> frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
> frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
> (lldb) fr v
> (MVMThreadContext *) tc = 0x000100500290
> (MVMSTable *) st = 0x000101004f40
> (void *) data = 
>
> (MVMGCWorklist *) worklist = 0x00010d27c1a0
> (MVMCallCaptureBody *) body =  out>
>
> (MVMArgProcContext *) ctx = 0x00010a6f3c00
> (MVMuint16) flag = 0
> (MVMuint16) i = 0
> (MVMuint16) count = 
>
> 

Re: [perl #127958] [BUG] :D smiley is not respected when assigning to Nil

[Lloyd Fournier]

Tests:
https://github.com/perl6/roast/commit/fa9a6b05f665bef3b5b45cb35d4018b2a8368c31

On Mon, Jul 25, 2016 at 8:19 AM Brian S. Julin via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Fri Jul 22 15:34:49 2016, b...@abrij.org wrote:
> >
> > rakudo PR #829 should fix this on moarvm.  JVM and JS fixes may also
> > be needed.
>
>
> I added some error awesomeization to that PR so that now:
>
> $ perl6 -e 'my Int:D @a; @a[0] = Nil; @a.say;'
> Type check failed in assignment to @a; expected type Int:D cannot be
> itself (perhaps Nil was assigned to a :D which had no default?)
>   in block  at -e line 1
>
> $ perl6 -e 'my Int:D @a; @a[0] = Int:D; @a.say;'
> Type check failed in assignment to @a; expected type Int:D cannot be
> itself (perhaps Nil was assigned to a :D which had no default?)
>   in block  at -e line 1
>
> $ perl6 -e 'my Int:D $a = 42; $a := Nil; $a.say;'
> Type check failed in binding; expected Int:D but got Nil (Nil)
>   in block  at -e line 1
>
> $ perl6 -e 'my Int:D $a = 42; $a := Int:D; $a.say;'
> Type check failed in binding; expected type Int:D cannot be itself
>   in block  at -e line 1
>
> And though there is an awesomeization for sub return types it does not
> work,
> because the X is being fed the raw type not the smilied typed.
>
> $ perl6 -e '{ sub f() of Str:D { Str:D }; f(); CATCH {
> $_.expected.WHAT.say }}'
> (Str)
> Type check failed for return value; expected Str but got Str:D (Str:D)
>   in sub f at -e line 1
>   in block  at -e line 1
>
> ...that is a separate issue so, not touching it.
>
> Another thing I'm not touching is this:
>
> $ perl6 -e 'my Int:D %a; %a := Str; %a.say;'
> {a => (Str)}
>
> ...note how the array version fails (correctly) in the binder:
>
> $ perl6 -e 'my Int:D @a; @a[0] := Str; @a.say;'
> Cannot resolve caller BIND-POS(Array[Int:D]: Int, Str); none of these
> signatures match:
> (Array:D $: Int $pos, Int:D \bindval, *%_)
> (Array:D $: int $pos, Int:D \bindval, *%_)
>   in block  at -e line 1
> $ perl6 -e 'my Int:D @a;
> @a.^find_method("BIND-POS").candidates».signature.say'
> ((Array:D $: Int $pos, Int:D \bindval, *%_) (Array:D $: int $pos, Int:D
> \bindval, *%_))
> $ perl6 -e 'my Int:D %a;
> %a.^find_method("BIND-KEY").candidates».signature.say'
> ((Hash:D $: \key, Mu \bindval, *%_))
>
> ...and note in Hash.pm there are comments on the hash class BIND-KEY
> method saying
> it should be a multi, but that blows up setting compilation -- I verified
> this is still
> currently the case.  That might be related.
>
> One thing the awesomeized errors do not get right is this, but it is in a
> half broken,
> half NYI state anyway:
>
> $ perl6 -e 'role A[::T $t] { has T:D $.f = 1; }; A[Int].new'
> X::TypeCheck::Assignment exception produced no message
>   in any  at gen/moar/m-Metamodel.nqp line 1736
>   in block  at -e line 1
>
> (versus current behavior, also wrong as it should not fail, if ever
> implemented):
>
> (03:31:08 PM) skids: m: role A[::T $t] { has T:D $.f = 1; }; A[Int].new
> (03:31:09 PM) camelia: rakudo-moar 478671: OUTPUT«Type check failed in
> assignment to $!f; expected T:D but got Int (1)␤  in any  at
> gen/moar/m-Metamodel.nqp line 1736␤  in block  at  line 1␤␤»
>
> Evidence that it should not be hoped to work:
>
> $ perl6 -e 'role A[::T $t] { method f { (T:D).perl.say } }; A[Int].new.f()'
> ===SORRY!=== Error while compiling -e
> Type too complex to form a definite type
> at -e:1
>
>
>

Re: [perl #128636] [BUG][PRECOMP] is cached in a precompiled module results in error

[Lloyd Fournier]

Hi Zoffix,

You reported the same bug in December :P

https://rt.perl.org/Public/Bug/Display.html?id=126818 (although the error
message has changed).

This is the compile time outer context serialization bug. FYI I've kept a
list of tickets that are examples of it:

https://rt.perl.org/Public/Bug/Display.html?id=125634
https://rt.perl.org/Public/Bug/Display.html?id=126818
https://rt.perl.org/Public/Bug/Display.html?id=127034
https://rt.perl.org/Public/Bug/Display.html?id=127112
https://rt.perl.org/Public/Bug/Display.html?id=127858
https://rt.perl.org/Public/Bug/Display.html?id=127860
https://rt.perl.org/Public/Bug/Display.html?id=127959
https://rt.perl.org/Public/Bug/Display.html?id=128636

On Sun, Jul 17, 2016 at 5:59 AM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #128636]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128636 >
>
>
> If `no precompilation` is added to A.pm6 , the error goes away.
>
> zoffix@VirtualBox:/tmp/tmp.YwbSHxhVWC$ cat A.pm6
> use experimental :cached;
> sub foo($x) is export is cached { $x }
> zoffix@VirtualBox:/tmp/tmp.YwbSHxhVWC$ perl6 -I. -MA -e 'foo 42'
> Cannot invoke this object (REPR: Null; VMNull)
>   in block  at
> /home/zoffix/.rakudobrew/moar-nom/install/share/perl6/sources/AAC61C0EC6F88780427830443A057030CAA33846
> (experimental) line 10
>   in any enter at gen/moar/m-Metamodel.nqp line 3963
>   in block  at -e line 1
>
>
> The issue appeared in one of these commits:
> https://github.com/rakudo/rakudo/compare/2c69ab78bed2d3f622d027e5e5a132ab212f3a77...bc722abe2cd7f9d34060ee6ff71065a00bedcc16
>
>
> Looking at the implementation of is cached, these two bugs may or may not
> be related:
> https://rt.perl.org/Ticket/Display.html?id=128476
> https://rt.perl.org/Ticket/Display.html?id=107844
>
>
>
> --
> Cheers,
> ZZ | https://twitter.com/zoffix
>

Re: [perl #128342] > assertion doesn't work if is zero-width

[Lloyd Fournier]

Ok. Thanks for the explanation Zoffix++. I guess you have to be careful
doing >.

On Thu, Jul 14, 2016 at 10:59 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:

> Hi,
>
> Thanks for the report.
>
> This is by design, as tokens don't backtrack.  works by flipping
> the string and the AST of the thing within it. So it's like doing "a" ~~
> /.?: a/. The .? is greedy, so it eats the 'a', doesn't backtrack, and the
> whole match fails.
>
> For example, using `regex` instead of `token` matches:
> zoffix@leliana:~$ perl6 -e 'my regex foo { .? }; say "a" ~~ /"a"  "a"  >/'
> ｢a｣
>
> And turning off backtracking for .? makes it not match, just as with
> `token`:
> zoffix@leliana:~$ perl6 -e 'say "a" ~~ /"a" /'
> Nil
>
> Relevant IRC conversation:
> http://irclog.perlgeek.de/perl6/2016-07-14#i_12840233
>
> --
> Cheers,
> ZZ | https://twitter.com/zoffix
>

Re: [perl #128553] multi method cache causes Base64 regression

[Lloyd Fournier]

By flag_map I mean ctx->callsite->arg_flags:

(lldb) p ctx->arg_flags
(MVMCallsiteEntry *) $8 = 0x
(lldb) p ctx->callsite->arg_flags
(MVMCallsiteEntry *) $9 = 0x10a72533 ""

On Mon, Jul 11, 2016 at 3:59 AM Lloyd Fournier 
wrote:

> I've been getting segfaults in this area recently. The trace is a bit
> different but I guess it's related. It seems that flag_map in gc_mark is no
> longer allocated so I get segfault.
>
> (lldb) r
> There is a running process, kill it and restart?: [Y/n] y
> Process 75673 exited with status = 9 (0x0009)
> Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
> (x86_64)
> Process 75691 stopped
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
> frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
>52  MVMuint16  count = ctx->arg_count;
>53  MVMuint16  i, flag;
>54  for (i = 0, flag = 0; i < count; i++, flag++) {
> -> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
>56  /* Current position is name, then next is value. */
>57  MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
>58  i++;
> (lldb) bt
> * thread #1: tid = 0x23cfc68, 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at
> MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x10a72533)
>   * frame #0: 0x000100063ca4
> libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
> data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
> frame #1: 0x00010003f002
> libmoar.dylib`MVM_gc_mark_collectable(tc=,
> worklist=, new_addr=) + 1714 at collect.c:399
> frame #2: 0x00010003e883
> libmoar.dylib`process_worklist(tc=0x000100500290,
> worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
> collect.c:313
> frame #3: 0x00010003e324
> libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
> what_to_do=, gen=) + 820 at collect.c:129
> frame #4: 0x00010003b703
> libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
> orchestrate.c:304
> frame #5: 0x00010003b4c8
> libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
> orchestrate.c:438
> frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate_nursery(tc=, size=) +
> 52 at allocation.c:32
> frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
> [inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
> frame #8: 0x00010003bc5d
> libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
> at allocation.c:49
> frame #9: 0x00010003bf44
> libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
> st=) + 84 at allocation.c:86
> frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
> st=) + 15 at P6opaque.c:60
> frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
> MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
> reprconv.c:13
> frame #12: 0x000100050d19
> libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
> type=0x000101626fc0, val=) + 73 at reprconv.c:586
> frame #13: 0x00019c07
> libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
> ex_obj=) +  at exceptions.c:407
> frame #14: 0x000100017488
> libmoar.dylib`MVM_interp_run(tc=0x000100500290,
> initial_invoke=, invoke_data=) + 47320 at
> interp.c:3830
> frame #15: 0x0001000c8305
> libmoar.dylib`MVM_vm_run_file(instance=,
> filename=) + 181 at moar.c:304
> frame #16: 0x0001170a moar`main(argc=,
> argv=0x7fff5fbff8e8) + 666 at main.c:191
> frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
> frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
> (lldb) fr v
> (MVMThreadContext *) tc = 0x000100500290
> (MVMSTable *) st = 0x000101004f40
> (void *) data = 
>
> (MVMGCWorklist *) worklist = 0x00010d27c1a0
> (MVMCallCaptureBody *) body =  out>
>
> (MVMArgProcContext *) ctx = 0x00010a6f3c00
> (MVMuint16) flag = 0
> (MVMuint16) i = 0
> (MVMuint16) count = 
>
> 

Re: [perl #128553] multi method cache causes Base64 regression

[Lloyd Fournier]

I've been getting segfaults in this area recently. The trace is a bit
different but I guess it's related. It seems that flag_map in gc_mark is no
longer allocated so I get segfault.

(lldb) r
There is a running process, kill it and restart?: [Y/n] y
Process 75673 exited with status = 9 (0x0009)
Process 75691 launched: '/Users/llfourn/src/rakudo/install/bin/moar'
(x86_64)
Process 75691 stopped
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
   52  MVMuint16  count = ctx->arg_count;
   53  MVMuint16  i, flag;
   54  for (i = 0, flag = 0; i < count; i++, flag++) {
-> 55  if (flag_map[flag] & MVM_CALLSITE_ARG_NAMED) {
   56  /* Current position is name, then next is value. */
   57  MVM_gc_worklist_add(tc, worklist, &ctx->args[i].s);
   58  i++;
(lldb) bt
* thread #1: tid = 0x23cfc68, 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at
MVMCallCapture.c:55, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x10a72533)
  * frame #0: 0x000100063ca4
libmoar.dylib`gc_mark(tc=0x000100500290, st=0x000101004f40,
data=, worklist=0x00010d27c1a0) + 84 at MVMCallCapture.c:55
frame #1: 0x00010003f002
libmoar.dylib`MVM_gc_mark_collectable(tc=,
worklist=, new_addr=) + 1714 at collect.c:399
frame #2: 0x00010003e883
libmoar.dylib`process_worklist(tc=0x000100500290,
worklist=0x00010d27c1a0, wtp=0x7fff5fbff468, gen='\0') + 899 at
collect.c:313
frame #3: 0x00010003e324
libmoar.dylib`MVM_gc_collect(tc=0x000100500290,
what_to_do=, gen=) + 820 at collect.c:129
frame #4: 0x00010003b703
libmoar.dylib`run_gc(tc=0x000100500290, what_to_do='\0') + 131 at
orchestrate.c:304
frame #5: 0x00010003b4c8
libmoar.dylib`MVM_gc_enter_from_allocator(tc=0x000100500290) + 984 at
orchestrate.c:438
frame #6: 0x00010003bca8 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate_nursery(tc=, size=) +
52 at allocation.c:32
frame #7: 0x00010003bc74 libmoar.dylib`MVM_gc_allocate_zeroed
[inlined] MVM_gc_allocate(tc=) + 23 at allocation.h:13
frame #8: 0x00010003bc5d
libmoar.dylib`MVM_gc_allocate_zeroed(tc=0x000100500290, size=40) + 13
at allocation.c:49
frame #9: 0x00010003bf44
libmoar.dylib`MVM_gc_allocate_object(tc=0x000100500290,
st=) + 84 at allocation.c:86
frame #10: 0x00010005813f libmoar.dylib`allocate(tc=,
st=) + 15 at P6opaque.c:60
frame #11: 0x000100050d27 libmoar.dylib`MVM_repr_box_str [inlined]
MVM_repr_alloc_init(tc=0x000100500290, type=0x000101626fc0) + 14 at
reprconv.c:13
frame #12: 0x000100050d19
libmoar.dylib`MVM_repr_box_str(tc=0x000100500290,
type=0x000101626fc0, val=) + 73 at reprconv.c:586
frame #13: 0x00019c07
libmoar.dylib`MVM_exception_backtrace(tc=0x000100500290,
ex_obj=) +  at exceptions.c:407
frame #14: 0x000100017488
libmoar.dylib`MVM_interp_run(tc=0x000100500290,
initial_invoke=, invoke_data=) + 47320 at
interp.c:3830
frame #15: 0x0001000c8305
libmoar.dylib`MVM_vm_run_file(instance=,
filename=) + 181 at moar.c:304
frame #16: 0x0001170a moar`main(argc=,
argv=0x7fff5fbff8e8) + 666 at main.c:191
frame #17: 0x7fff900c05ad libdyld.dylib`start + 1
frame #18: 0x7fff900c05ad libdyld.dylib`start + 1
(lldb) fr v
(MVMThreadContext *) tc = 0x000100500290
(MVMSTable *) st = 0x000101004f40
(void *) data = 

(MVMGCWorklist *) worklist = 0x00010d27c1a0
(MVMCallCaptureBody *) body = 

(MVMArgProcContext *) ctx = 0x00010a6f3c00
(MVMuint16) flag = 0
(MVMuint16) i = 0
(MVMuint16) count = 

(MVMuint8 *) flag_map = 0x10a72533 ""
(lldb) p flag_map
(MVMuint8 *) $6 = 0x10a72533 ""
(lldb) p flag_map[0]
error: Couldn't apply expression side effects : Couldn't dematerialize a
result variable: couldn't read its memory

On Sun, Jul 10, 2016 at 12:19 AM jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Tue Jul 05 17:51:46 2016, ug...@cpan.org wrote:
> > Note that the final decode-base64 candidate shows the correct results
> > when debugging statements are added
> >
> > This gist also shows a small change that makes it produce the correct
> > values but it still segfaults more often than not
> > https://gist.github.com/ugexe/baa168a641894a0731595c812724f76d
>
> Having dug into it a little, I'm not sure that the new multi-caching stuff
> has caused this, so much as uncovered it (perhaps by moving GC colle

Re: [perl #128516] [SEGV] $!attr.^compose causing segfault

[Lloyd Fournier]

Further information: if you put nqp::decont($!a).^compose it works.

On Wed, Jul 6, 2016 at 4:26 AM Nicholas Clark  wrote:

> On Fri, Jul 01, 2016 at 10:36:25PM -0700, Lloyd Fournier wrote:
>
> > class Foo { has $.a = Metamodel::ClassHOW.new_type(name => "Bar"); method
> > comp { $!a.^compose } };
> > my $obj = Foo.new;
> > $obj.comp;
> > say $obj;
>
> When I run that, I get this:
>
> moar: src/gc/roots.c:245: MVM_gc_root_gen2_add: Assertion `!(c->flags &
> MVM_CF_FORWARDER_VALID)' failed.
> Aborted
>
> (I wasn't paying close attention, but I guess I built with full-on
> debugging
> flags)
>
> I hope that makes it more obvious to someone how to fix this.
>
> Nicholas Clark
>

Re: [perl #128543] [BUG] Str.Int inconsistent about spaces on empty string

[Lloyd Fournier]

err now that I actually check with warnings it seems I'm wrong and "" " "
both give the same warning.

perl -E 'use warnings; use strict; say 1 + ""'
Argument "" isn't numeric in addition (+) at -e line 1.
1
perl -E 'use warnings; use strict; say 1 + " "'
Argument " " isn't numeric in addition (+) at -e line 1.
1

me bad.

On Wed, Jul 6, 2016 at 2:22 AM Lloyd Fournier  wrote:

> I think this is to be consistent with p5.
> perl -E 'say "" + 1' #-> 1
>
> I'm not really making an argument it should be this way. But that's
> probably the reason.
>
> On Wed, Jul 6, 2016 at 2:13 AM Zefram 
> wrote:
>
>> # New Ticket Created by  Zefram
>> # Please include the string:  [perl #128543]
>> # in the subject line of all future correspondence about this issue.
>> # https://rt.perl.org/Ticket/Display.html?id=128543 >
>>
>>
>> Is it permitted to have no digits at all when coercing a Str to Int?
>> The behaviour is inconsistent:
>>
>> > "".Int
>> 0
>> > " ".Int
>> Cannot coerce NaN to an Int
>>   in block  at  line 1
>>
>> Observing that spaces are permitted when there are digits, it would
>> seem that for consistency spaces should also make no difference to the
>> treatment of an otherwise-empty string.
>>
>> -zefram
>>
>

Re: [perl #128543] [BUG] Str.Int inconsistent about spaces on empty string

[Lloyd Fournier]

I think this is to be consistent with p5.
perl -E 'say "" + 1' #-> 1

I'm not really making an argument it should be this way. But that's
probably the reason.

On Wed, Jul 6, 2016 at 2:13 AM Zefram  wrote:

> # New Ticket Created by  Zefram
> # Please include the string:  [perl #128543]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128543 >
>
>
> Is it permitted to have no digits at all when coercing a Str to Int?
> The behaviour is inconsistent:
>
> > "".Int
> 0
> > " ".Int
> Cannot coerce NaN to an Int
>   in block  at  line 1
>
> Observing that spaces are permitted when there are digits, it would
> seem that for consistency spaces should also make no difference to the
> treatment of an otherwise-empty string.
>
> -zefram
>

Re: [perl #128483] [BUG][PRECOMPILATION] Issues with CALLER invocations in a precompiled module with subs exported by a zef/panda installed module

[Lloyd Fournier]

I think this is another *compile-time closure loses it's outer ctx at
runtime* bug. I was trying to keep track of them:
https://rt.perl.org/Public/Bug/Display.html?id=125634

Your lovely module has a compile time closure here (EXPORT Is called at
compile time):

https://github.com/zoffixznet/perl6-Pretty-Topic/blob/master/lib/Pretty/Topic.pm6#L8

If you actually did do:

 sub term:<♥> is export { $CALLER::_ }

it would probably work.

On Sat, Jun 25, 2016 at 11:19 PM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #128483]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128483 >
>
>
> The Pretty::Topic module exports this sub:
>
>   sub term:<♥> { $CALLER::_ }
>
> If a user-made module uses Pretty::Topic and invokes that sub, `Cannot
> invoke this object` error occurs. The error goes away if the user-made
> module has `no precompilation` pragma. The issue does not occur if the sub
> term:<♥> { $CALLER::_ } is defined in a user-made module (and not something
> installed with panda/zef) or if the Pretty::Topic is included in a script
> and not a precompiled module:
>
>
> $ tree
> .
> └── A.pm6
>
> 0 directories, 1 file
>
> $ cat A.pm6
> unit class A;
> use Pretty::Topic '♥';
> method update { say ♥ for ^4; }
>
> $ perl6 -I. -MA -e 'A.new.update'
> Cannot invoke this object
>   in sub  at sources/EDE2FE63DE5B1C96179DD91E427A5419C919578A
> (Pretty::Topic) line 8
>   in method update at /tmp/tmp.97W1AJFY3o/A.pm6 (A) line 3
>   in block  at -e line 1
>
> $ pico A.pm6
>
> $ cat A.pm6
> no precompilation;
> unit class A;
> use Pretty::Topic '♥';
> method update { say ♥ for ^4; }
>
> $ perl6 -I. -MA -e 'A.new.update'
> 0
> 1
> 2
> 3
> $
>
> $ perl6 -e 'use Pretty::Topic "♥"; say ♥ for ^4;'
> 0
> 1
> 2
> 3
>

Re: [perl #128481] [BUG] *.split returns a BOOTArray

[Lloyd Fournier]

Test:
https://github.com/perl6/roast/commit/0d86018d749317b859e36dad1e4520950fad0e9f

On Sun, Jun 26, 2016 at 1:36 AM Lloyd Fournier 
wrote:

> will write test tomorrow.
> Thx liz.
>
> On Sun, Jun 26, 2016 at 1:35 AM Elizabeth Mattijsen via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> Fixed with 0e4a6434d6164169ba , tests needed
>>
>> > On 25 Jun 2016, at 06:28, Lloyd Fournier (via RT) <
>> perl6-bugs-follo...@perl.org> wrote:
>> >
>> > # New Ticket Created by  Lloyd Fournier
>> > # Please include the string:  [perl #128481]
>> > # in the subject line of all future correspondence about this issue.
>> > # https://rt.perl.org/Ticket/Display.html?id=128481 >
>> >
>> >
>> > 20:26 < llfourn> m: my &code = *.split("\n");
>> code("foo\nbar").^name.say #
>> > :/
>> > 20:26 <+camelia> rakudo-moar 6afd0b: OUTPUT«BOOTArray␤»
>>
>>
>>

Re: [perl #128481] [BUG] *.split returns a BOOTArray

[Lloyd Fournier]

will write test tomorrow.
Thx liz.

On Sun, Jun 26, 2016 at 1:35 AM Elizabeth Mattijsen via RT <
perl6-bugs-follo...@perl.org> wrote:

> Fixed with 0e4a6434d6164169ba , tests needed
>
> > On 25 Jun 2016, at 06:28, Lloyd Fournier (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
> >
> > # New Ticket Created by  Lloyd Fournier
> > # Please include the string:  [perl #128481]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=128481 >
> >
> >
> > 20:26 < llfourn> m: my &code = *.split("\n"); code("foo\nbar").^name.say
> #
> > :/
> > 20:26 <+camelia> rakudo-moar 6afd0b: OUTPUT«BOOTArray␤»
>
>
>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

@FROGGS for me that test passes with
https://github.com/rakudo/rakudo/commit/491af6034d

(without
your fix).
Your commit did fix the issue of the file's content changing (and therefore
the SHA) causing re-precompilation to be broken:

Tests for that:
https://github.com/perl6/roast/commit/cef40ed6be09d8ac8257df3509cf840c8c82dc87

\o/ precomp works again. Thanks all!

On Mon, Jun 13, 2016 at 3:22 AM Tobias Leich via RT <
bugs-comm...@bugs6.perl.org> wrote:

> These patches fix and test the remaining issue:
>   https://github.com/rakudo/rakudo/commit/d0a00164e9
>   https://github.com/perl6/roast/commit/716b94f7ff
>
>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

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

On Sat, Jun 11, 2016 at 8:38 AM Lloyd Fournier 
wrote:

> another one:
>
> https://rt.perl.org/Public/Bug/Display.html?id=128156
>
> On Tue, Jun 7, 2016 at 9:29 PM Lloyd Fournier 
> wrote:
>
>> I've tested both issues with the branch:
>>
>> issue #1 (changing dependency contents leads to goofed re-precomp) --
>> Still broken
>> issue #2 (collisions on timestamps leads to goofed re-precomp) -- Fixed!
>>
>> for reference another example of issue #1 was reported recently:
>>
>> https://rt.perl.org/Public/Bug/Display.html?id=128332
>>
>> On Tue, May 24, 2016 at 8:17 PM mt1957  wrote:
>>
>>> Hi,
>>>
>>> Another symptom from the same bug. After modifying a sub module I get an
>>> error like the following;
>>>
>>>
>>> Type 'Semi-xml::Sxml' is not declared
>>> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
>>> --> my Semi-xml::Sxml⏏ $x .= new;
>>> Malformed my
>>> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
>>> --> my Semi-xml::⏏Sxml $x .= new;
>>>
>>>
>>> Then, after modifying the top module (just a simple say), everything
>>> runs ok again.
>>>
>>> This is Rakudo version 2016.04-209-gdb10a01 built on MoarVM version
>>> 2016.04-134-g9879233
>>>
>>> Greetings,
>>> Marcel
>>>
>>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

another one:

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

On Tue, Jun 7, 2016 at 9:29 PM Lloyd Fournier  wrote:

> I've tested both issues with the branch:
>
> issue #1 (changing dependency contents leads to goofed re-precomp) --
> Still broken
> issue #2 (collisions on timestamps leads to goofed re-precomp) -- Fixed!
>
> for reference another example of issue #1 was reported recently:
>
> https://rt.perl.org/Public/Bug/Display.html?id=128332
>
> On Tue, May 24, 2016 at 8:17 PM mt1957  wrote:
>
>> Hi,
>>
>> Another symptom from the same bug. After modifying a sub module I get an
>> error like the following;
>>
>>
>> Type 'Semi-xml::Sxml' is not declared
>> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
>> --> my Semi-xml::Sxml⏏ $x .= new;
>> Malformed my
>> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
>> --> my Semi-xml::⏏Sxml $x .= new;
>>
>>
>> Then, after modifying the top module (just a simple say), everything
>> runs ok again.
>>
>> This is Rakudo version 2016.04-209-gdb10a01 built on MoarVM version
>> 2016.04-134-g9879233
>>
>> Greetings,
>> Marcel
>>
>

Re: [perl #128371] precompilation bug

[Lloyd Fournier]

This is another of RT #128156

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

On Sat, Jun 11, 2016 at 4:27 AM via RT  wrote:

> # New Ticket Created by
> # Please include the string:  [perl #128371]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128371 >
>
>
> This bug is a touch complex.
>
> First, file layout -
>
> bug/bin/perl6-prolog-lrep
> bug/lib/Prolog/{Actions.pm6,Grammar.pm6,LREP.pm6}
>
> As it stands, running:
>
> perl6 -Ilib bin/perl6-prolog-lrep
>
> # displays the prompt '> ' with Linenoise.
>
> Perl6 precompiles the .pm6 modules so things will run faster next time.
> Now, open Grammar.pm and add a '#" comment at the point marked '#^-- Add
> a comment here, rerun bin/perl6-prolog-lrep'.
>
> Rerun bin/perl6-prolog-lrep, and now you get this random-seeming error
> message:
>
> --cut here--
> Could not find symbol '&here'
>   in block  at bin/perl6-prolog-lrep line 5
>
> Actually thrown at:
>   in block  at bin/perl6-prolog-lrep line 5
> --cut here--
>
> Delete the lib/.precomp directory and the problem goes away.
>
> I suspect the precompilation routines should expire the old .precomp
> files, but aren't because the change is in a 'grammar' block, and not a
> 'class' block. I have no proof of that, but that's my suspicion.
>
> If you have questions, the easiest way to get hold of me is on IRC.
>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

I've tested both issues with the branch:

issue #1 (changing dependency contents leads to goofed re-precomp) -- Still
broken
issue #2 (collisions on timestamps leads to goofed re-precomp) -- Fixed!

for reference another example of issue #1 was reported recently:

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

On Tue, May 24, 2016 at 8:17 PM mt1957  wrote:

> Hi,
>
> Another symptom from the same bug. After modifying a sub module I get an
> error like the following;
>
>
> Type 'Semi-xml::Sxml' is not declared
> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
> --> my Semi-xml::Sxml⏏ $x .= new;
> Malformed my
> at /home/marcel/Languages/Perl6/Projects/Semi-xml/t/108-xml.t:43
> --> my Semi-xml::⏏Sxml $x .= new;
>
>
> Then, after modifying the top module (just a simple say), everything
> runs ok again.
>
> This is Rakudo version 2016.04-209-gdb10a01 built on MoarVM version
> 2016.04-134-g9879233
>
> Greetings,
> Marcel
>

Re: [perl #128332] [BUG] changing source file results in "Missing or wrong version of dependency"

[Lloyd Fournier]

This is covered in:

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

On Tue, Jun 7, 2016 at 6:24 AM Tobias Leich 
wrote:

> # New Ticket Created by  Tobias Leich
> # Please include the string:  [perl #128332]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128332 >
>
>
> I've got the following files:
>
> ~/dev/rakudo/test$ tree .
> .
> ├── A.pm
> ├── B.pm
> └── C.pm
>
>
> $ cat A.pm
> use C :foo;
> use B;
>
> $ cat B.pm
> use C :foo;
>
> $ cat C.pm
> use v6;
> use nqp;
> use NativeCall;
> my class CStruct is repr('CStruct') is export(:foo) { }
> # my class CStruct is repr('CStruct') { }
>
> When I run this code once:
> $ perl6 -I. -MA -e ''
>
> All is fine... But when I run it again after adding an empty line to
> file C.pm I get:
>   perl6 -I. -MA -e ''
> ===SORRY!===
> Missing or wrong version of dependency
> '/home/froggs/dev/rakudo/test/C.pm (C)' (from
> '/home/froggs/dev/rakudo/test/B.pm (B)')
>
>

Re: [perl #128314] AutoReply: stubbed sub in RHS of constant not being updated

[Lloyd Fournier]

see http://irclog.perlgeek.de/perl6/2016-06-03#i_12599481 for jnthn comments

On Fri, Jun 3, 2016 at 10:28 PM perl6 via RT 
wrote:

> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "stubbed sub in RHS of constant not being updated",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [perl #128314].
>
> Please include the string:
>
>  [perl #128314]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> perl6-bugs-follo...@perl.org
>
> -
> m: sub f {...}; our constant @a = lazy map { f() }, ^Inf; sub f { rand };
> say @a[^3]
> 22:14 <+camelia> rakudo-moar dfbf1e: OUTPUT«Stub code executed␤
>
> grondilu++ for picking this up
>
> Since the RHS of the constant is actually being run at runtime and not
> BEGIN the reference to it should not be point to the definition but it's
> still executing the sub.
>
>

Re: [perl #128277] [BUG] Definitely typed variables have wrong default

[Lloyd Fournier]

^^ but that was wrong too.

Type check failed in assignment to $a; expected Str:D but got Nil

Going to go lie down for a bit now


On Sat, May 28, 2016 at 10:02 PM Lloyd Fournier 
wrote:

> Should be:
>
> Type check failed in assignment to $a; expected Str:D but got (Mu)
>
> (sorry for the spam)
>
> On Sat, May 28, 2016 at 10:00 PM Lloyd Fournier 
> wrote:
>
>> (continued :P)
>> Type check failed in assignment to $a; expected Str:D but got Mu (Mu)
>>   in block  at -e line 1
>>
>> It can also happen on assignment to array and hash elements.
>>
>> On Sat, May 28, 2016 at 9:59 PM Lloyd Fournier <
>> perl6-bugs-follo...@perl.org> wrote:
>>
>>> # New Ticket Created by  Lloyd Fournier
>>> # Please include the string:  [perl #128277]
>>> # in the subject line of all future correspondence about this issue.
>>> # https://rt.perl.org/Ticket/Display.html?id=128277 >
>>>
>>>
>>> my Str:D $a = Nil; say $a; # (Str:D)
>>> say $a.VAR.default; #(Str:D)
>>>
>>> :D variables in general cannot have a default default. Therefore if the
>>> default default should be to throw an exception when it is acessed. My
>>> answer would be:
>>>
>>

Re: [perl #128277] [BUG] Definitely typed variables have wrong default

[Lloyd Fournier]

Should be:

Type check failed in assignment to $a; expected Str:D but got (Mu)

(sorry for the spam)

On Sat, May 28, 2016 at 10:00 PM Lloyd Fournier 
wrote:

> (continued :P)
> Type check failed in assignment to $a; expected Str:D but got Mu (Mu)
>   in block  at -e line 1
>
> It can also happen on assignment to array and hash elements.
>
> On Sat, May 28, 2016 at 9:59 PM Lloyd Fournier <
> perl6-bugs-follo...@perl.org> wrote:
>
>> # New Ticket Created by  Lloyd Fournier
>> # Please include the string:  [perl #128277]
>> # in the subject line of all future correspondence about this issue.
>> # https://rt.perl.org/Ticket/Display.html?id=128277 >
>>
>>
>> my Str:D $a = Nil; say $a; # (Str:D)
>> say $a.VAR.default; #(Str:D)
>>
>> :D variables in general cannot have a default default. Therefore if the
>> default default should be to throw an exception when it is acessed. My
>> answer would be:
>>
>

Re: [perl #128277] [BUG] Definitely typed variables have wrong default

[Lloyd Fournier]

(continued :P)
Type check failed in assignment to $a; expected Str:D but got Mu (Mu)
  in block  at -e line 1

It can also happen on assignment to array and hash elements.

On Sat, May 28, 2016 at 9:59 PM Lloyd Fournier 
wrote:

> # New Ticket Created by  Lloyd Fournier
> # Please include the string:  [perl #128277]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128277 >
>
>
> my Str:D $a = Nil; say $a; # (Str:D)
> say $a.VAR.default; #(Str:D)
>
> :D variables in general cannot have a default default. Therefore if the
> default default should be to throw an exception when it is acessed. My
> answer would be:
>

Re: [perl #128268] "Could not find symbol" error occurs when you use module A::B::C within A::B's class definition

[Lloyd Fournier]

Looks similar to RT #128156.

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

On Fri, May 27, 2016 at 10:49 PM Rob Hoelz 
wrote:

> # New Ticket Created by  Rob Hoelz
> # Please include the string:  [perl #128268]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128268 >
>
>
> I found this issue when trying to use XML::Query; the attached tarball has
> a golfed-down example.  I've also attached a picture that illustrates the
> "use" relationship between the various units.
>
> When I try to run test.pl in the tarball, I get the following error:
>
> > ===SORRY!===
> > Could not find symbol '&B'
>
> Disabling precompilation fixes the issue, as does rearranging the contents
> of lib/Common/A.pm so that "use Common::A::B" comes before "unit class
> Common::A".  Removing any seemingly superfluous use statement fixes the
> issue, so it appears this is one of those wacky dependency graph + precomp
> bugs.

Re: [perl #128156] dependency errors

[Lloyd Fournier]

wrt to outdating files. What I would actually expect from looking at the
code is for it to fail to produce a valid $handle and fallback to
non-precomp loading.

my $handle = (
self.may-precomp and (
my $loaded = self.load($id, :since($source.modified),
:@precomp-stores) # already precompiled?
or self.precompile($source, $id,
:source-name($dependency.source-name), :force($loaded ~~ Failure))
and self.load($id, :@precomp-stores) # if not do it now
)
);

1. File changes at timestamp X
2. p6 is run at timestamp X
3. p6 detects file has changed in the first self.load() (so it returns a
fail "Outdated precompiled $unit")
4. so it does a :force recompile
5. then tries to self.load() a second time -- but because we are still at
time X the second load still returns failure
6. $precompiled gets set to False (which means a fallback non-precomp load
should be used)

After a few "note"s around the place the above seems to be what is
happening but I could be wrong.
I'm not sure how we end up with the current failure mode (symbols missing
from GLOBAL). The only thing that stands out to me is that it's
nqp::exit(0) ie exit success, when precomp fails. I don't have a picture in
my mind of the whole process yet so exit(0) might make sense. This
precompilation is complicated stuff!

On Mon, May 23, 2016 at 10:13 AM Lloyd Fournier 
wrote:

> I've done some more investigation. There are two seperate issues:
>
> 1. The main issue wrt this ticket. It hits you will you are editing code.
> It can be reproduced (on any platform) with:
>
> P6="perl6"
> lib="templib"
> test -e $lib && rm -r $lib;
> mkdir $lib
> sleep="sleep 2";
> echo 'class Top1 { }; need Needed;' > $lib/Top1.pm6
> echo 'class Needed { };'  > $lib/Needed.pm6;
> echo 'class Top2 { }; need Needed;'   > $lib/Top2.pm6;
>
> while true; do
> printf '#' >> $lib/Needed.pm6 # touch isn't enough here
> $sleep;
> $P6 -I$lib -e 'need Top1; need Top2; say GLOBAL::.keys;'
> done
>
> 
> which will fail on the second iteration of the loop:
>
> (Top2 Needed Top1)
> ===SORRY!===
> Missing or wrong version of dependency '/root/templib3/Needed.pm6
> (Needed)' (from '/root/templib3/Top2.pm6 (Top2)')
>
> This one is different because the content of the file has to actually
> change rather than just the mtime to trigger it.
>
> 2. A smaller issue which is what I was investigating in the prior
> response. If you load/recompile a compunit in the same second as the source
> is modified it will fail. (your processor and disk has to be fast enough to
> pull this off which I *think* is why nine couldn't reproduce it rather than
> this being a mac specific thing).
>
> This race condition essentially happens in this  line in
> !load-dependencies:
>
> return False if not $srcIO.e or $modified <= $srcIO.modified;
>
> because it's <= it opens the possibility that a precomp is marked as out
> of date a second time even after it has just been re-precompiled in the
> same process. The consequence seems to be a bad serialisation. (of course
> I'm not suggesting it shouldn't be <= but I guess the fact that something
> has just been re-precompiled should override this check).
>
>
> On Sun, May 22, 2016 at 7:12 AM Lloyd Fournier 
> wrote:
>
>> nine++ has attempted to fix this issue:
>>
>>
>> https://github.com/rakudo/rakudo/commit/c59e4dc44772cb09edeb8aa7f0ce0385f951cf5d
>>
>> Though it seems to have made the failure more random.
>>
>> Try the following:
>> while true; do
>> test -e lib && rm -r lib; # this is needed to trigger it for some
>> reason
>> mkdir lib;
>> echo 'class One { }; need Two;' > lib/One.pm6
>> echo 'class Two { }; need Three;' > lib/Two.pm6
>> echo '' > lib/Three.pm6
>> perl6 -Ilib -e 'need One;'
>> touch lib/Three.pm6
>> perl6 -Ilib -e 'need One; say GLOBAL::.keys;'
>> done
>>
>> gives me:
>>
>> (Two One)
>> ()
>> (Two One)
>> ()
>> (Two One)
>> ()
>> (Two One)
>> (Two One)
>> (Two One)
>> (Two One)
>> (Two One)
>> ()
>>
>> I wrote a test and push it to roast.
>>
>>
>> https://github.com/perl6/roast/commit/4e8b2e02e77e607593907380d30898ff5a926bd7
>>
>> It seems to have the same issue.
>>
>> On Sat, May 21, 2016 at 1:45 AM Lloyd Fournier 
>> wrote:
>>
>>&

Re: [perl #128156] dependency errors

[Lloyd Fournier]

I've done some more investigation. There are two seperate issues:

1. The main issue wrt this ticket. It hits you will you are editing code.
It can be reproduced (on any platform) with:

P6="perl6"
lib="templib"
test -e $lib && rm -r $lib;
mkdir $lib
sleep="sleep 2";
echo 'class Top1 { }; need Needed;' > $lib/Top1.pm6
echo 'class Needed { };'  > $lib/Needed.pm6;
echo 'class Top2 { }; need Needed;'   > $lib/Top2.pm6;

while true; do
printf '#' >> $lib/Needed.pm6 # touch isn't enough here
$sleep;
$P6 -I$lib -e 'need Top1; need Top2; say GLOBAL::.keys;'
done


which will fail on the second iteration of the loop:

(Top2 Needed Top1)
===SORRY!===
Missing or wrong version of dependency '/root/templib3/Needed.pm6 (Needed)'
(from '/root/templib3/Top2.pm6 (Top2)')

This one is different because the content of the file has to actually
change rather than just the mtime to trigger it.

2. A smaller issue which is what I was investigating in the prior response.
If you load/recompile a compunit in the same second as the source is
modified it will fail. (your processor and disk has to be fast enough to
pull this off which I *think* is why nine couldn't reproduce it rather than
this being a mac specific thing).

This race condition essentially happens in this  line in !load-dependencies:

return False if not $srcIO.e or $modified <= $srcIO.modified;

because it's <= it opens the possibility that a precomp is marked as out of
date a second time even after it has just been re-precompiled in the same
process. The consequence seems to be a bad serialisation. (of course I'm
not suggesting it shouldn't be <= but I guess the fact that something has
just been re-precompiled should override this check).


On Sun, May 22, 2016 at 7:12 AM Lloyd Fournier 
wrote:

> nine++ has attempted to fix this issue:
>
>
> https://github.com/rakudo/rakudo/commit/c59e4dc44772cb09edeb8aa7f0ce0385f951cf5d
>
> Though it seems to have made the failure more random.
>
> Try the following:
> while true; do
> test -e lib && rm -r lib; # this is needed to trigger it for some
> reason
> mkdir lib;
> echo 'class One { }; need Two;' > lib/One.pm6
> echo 'class Two { }; need Three;' > lib/Two.pm6
> echo '' > lib/Three.pm6
> perl6 -Ilib -e 'need One;'
> touch lib/Three.pm6
> perl6 -Ilib -e 'need One; say GLOBAL::.keys;'
> done
>
> gives me:
>
> (Two One)
> ()
> (Two One)
> ()
> (Two One)
> ()
> (Two One)
> (Two One)
> (Two One)
> (Two One)
> (Two One)
> ()
>
> I wrote a test and push it to roast.
>
>
> https://github.com/perl6/roast/commit/4e8b2e02e77e607593907380d30898ff5a926bd7
>
> It seems to have the same issue.
>
> On Sat, May 21, 2016 at 1:45 AM Lloyd Fournier 
> wrote:
>
>> It seems to have been introduced by one of nine's commits on the 13th.
>> This or one of the commits just before it I think:
>>
>>
>> https://github.com/rakudo/rakudo/commit/4fb3f94fcd39699f69e9d175315f9f1357e8faf3
>>
>>
>> On Fri, May 20, 2016 at 11:26 PM Lloyd Fournier 
>> wrote:
>>
>>> err leme try that again
>>>
>>> Precomp is broken for dependency chains 3 or longer when one of the
>>> dependencies down the chain is *changed*.
>>>
>>> To expand: Sometimes it gives you a problem where you get "Missing or
>>> wrong version of dependency" and sometimes symbols that should have been
>>> merged from GLOBALish just aren't there which is the case in the example
>>> above.
>>>
>>> On Fri, May 20, 2016 at 11:18 PM Lloyd Fournier 
>>> wrote:
>>>
>>>> I've been getting something similar and I've managed to golf it.
>>>>
>>>> mkdir lib;
>>>> echo 'class One { }; need Two;' > lib/One.pm6
>>>> echo 'class Two { }; need Three;' > lib/Two.pm6
>>>> echo '' > lib/Three.pm6
>>>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT
>>>> OK")'
>>>> echo "changing file" && touch lib/Two.pm6 # Three.pm6 will also break
>>>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT
>>>> OK")'
>>>>
>>>> summary:  Precomp is broken for dependency chains 3 or longer when one
>>>> of the dependencies down the chain is broken.
>>>>
>>>> Do we have a way of writing tests for prec

Re: [perl #128156] dependency errors

[Lloyd Fournier]

nine++ has attempted to fix this issue:

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

Though it seems to have made the failure more random.

Try the following:
while true; do
test -e lib && rm -r lib; # this is needed to trigger it for some reason
mkdir lib;
echo 'class One { }; need Two;' > lib/One.pm6
echo 'class Two { }; need Three;' > lib/Two.pm6
echo '' > lib/Three.pm6
perl6 -Ilib -e 'need One;'
touch lib/Three.pm6
perl6 -Ilib -e 'need One; say GLOBAL::.keys;'
done

gives me:

(Two One)
()
(Two One)
()
(Two One)
()
(Two One)
(Two One)
(Two One)
(Two One)
(Two One)
()

I wrote a test and push it to roast.

https://github.com/perl6/roast/commit/4e8b2e02e77e607593907380d30898ff5a926bd7

It seems to have the same issue.

On Sat, May 21, 2016 at 1:45 AM Lloyd Fournier 
wrote:

> It seems to have been introduced by one of nine's commits on the 13th.
> This or one of the commits just before it I think:
>
>
> https://github.com/rakudo/rakudo/commit/4fb3f94fcd39699f69e9d175315f9f1357e8faf3
>
>
> On Fri, May 20, 2016 at 11:26 PM Lloyd Fournier 
> wrote:
>
>> err leme try that again
>>
>> Precomp is broken for dependency chains 3 or longer when one of the
>> dependencies down the chain is *changed*.
>>
>> To expand: Sometimes it gives you a problem where you get "Missing or
>> wrong version of dependency" and sometimes symbols that should have been
>> merged from GLOBALish just aren't there which is the case in the example
>> above.
>>
>> On Fri, May 20, 2016 at 11:18 PM Lloyd Fournier 
>> wrote:
>>
>>> I've been getting something similar and I've managed to golf it.
>>>
>>> mkdir lib;
>>> echo 'class One { }; need Two;' > lib/One.pm6
>>> echo 'class Two { }; need Three;' > lib/Two.pm6
>>> echo '' > lib/Three.pm6
>>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
>>> echo "changing file" && touch lib/Two.pm6 # Three.pm6 will also break
>>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
>>>
>>> summary:  Precomp is broken for dependency chains 3 or longer when one
>>> of the dependencies down the chain is broken.
>>>
>>> Do we have a way of writing tests for precomp?
>>>
>>>
>>>
>>>
>>> On Tue, May 17, 2016 at 4:23 AM mt1957 
>>> wrote:
>>>
>>>> # New Ticket Created by  mt1957
>>>> # Please include the string:  [perl #128156]
>>>> # in the subject line of all future correspondence about this issue.
>>>> # https://rt.perl.org/Ticket/Display.html?id=128156 >
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I get the following error more often than before after some edits in my
>>>> source files.
>>>>
>>>> Missing or wrong version of dependency
>>>>
>>>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Wire.pm6
>>>> (MongoDB::Wire)' (from
>>>>
>>>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Cursor.pm6
>>>> (MongoDB::Cursor)'
>>>>
>>>> A remedy to this is to touch all source files in the library I work on
>>>> and than retry. I think that this should not happen, at least not that
>>>> often (I've seen it several times in about a week I think, twice this
>>>> evening, to give an idea).
>>>>
>>>> This is Rakudo version 2016.04-200-gad82657 built on MoarVM version
>>>> 2016.04-134-g9879233
>>>> implementing Perl 6.c.
>>>>
>>>> Greetings,
>>>> Marcel
>>>>
>>>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

It seems to have been introduced by one of nine's commits on the 13th. This
or one of the commits just before it I think:

https://github.com/rakudo/rakudo/commit/4fb3f94fcd39699f69e9d175315f9f1357e8faf3

On Fri, May 20, 2016 at 11:26 PM Lloyd Fournier 
wrote:

> err leme try that again
>
> Precomp is broken for dependency chains 3 or longer when one of the
> dependencies down the chain is *changed*.
>
> To expand: Sometimes it gives you a problem where you get "Missing or
> wrong version of dependency" and sometimes symbols that should have been
> merged from GLOBALish just aren't there which is the case in the example
> above.
>
> On Fri, May 20, 2016 at 11:18 PM Lloyd Fournier 
> wrote:
>
>> I've been getting something similar and I've managed to golf it.
>>
>> mkdir lib;
>> echo 'class One { }; need Two;' > lib/One.pm6
>> echo 'class Two { }; need Three;' > lib/Two.pm6
>> echo '' > lib/Three.pm6
>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
>> echo "changing file" && touch lib/Two.pm6 # Three.pm6 will also break
>> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
>>
>> summary:  Precomp is broken for dependency chains 3 or longer when one
>> of the dependencies down the chain is broken.
>>
>> Do we have a way of writing tests for precomp?
>>
>>
>>
>>
>> On Tue, May 17, 2016 at 4:23 AM mt1957 
>> wrote:
>>
>>> # New Ticket Created by  mt1957
>>> # Please include the string:  [perl #128156]
>>> # in the subject line of all future correspondence about this issue.
>>> # https://rt.perl.org/Ticket/Display.html?id=128156 >
>>>
>>>
>>> Hi,
>>>
>>> I get the following error more often than before after some edits in my
>>> source files.
>>>
>>> Missing or wrong version of dependency
>>>
>>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Wire.pm6
>>> (MongoDB::Wire)' (from
>>>
>>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Cursor.pm6
>>> (MongoDB::Cursor)'
>>>
>>> A remedy to this is to touch all source files in the library I work on
>>> and than retry. I think that this should not happen, at least not that
>>> often (I've seen it several times in about a week I think, twice this
>>> evening, to give an idea).
>>>
>>> This is Rakudo version 2016.04-200-gad82657 built on MoarVM version
>>> 2016.04-134-g9879233
>>> implementing Perl 6.c.
>>>
>>> Greetings,
>>> Marcel
>>>
>>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

err leme try that again

Precomp is broken for dependency chains 3 or longer when one of the
dependencies down the chain is *changed*.

To expand: Sometimes it gives you a problem where you get "Missing or wrong
version of dependency" and sometimes symbols that should have been merged
from GLOBALish just aren't there which is the case in the example above.

On Fri, May 20, 2016 at 11:18 PM Lloyd Fournier 
wrote:

> I've been getting something similar and I've managed to golf it.
>
> mkdir lib;
> echo 'class One { }; need Two;' > lib/One.pm6
> echo 'class Two { }; need Three;' > lib/Two.pm6
> echo '' > lib/Three.pm6
> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
> echo "changing file" && touch lib/Two.pm6 # Three.pm6 will also break
> perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
>
> summary:  Precomp is broken for dependency chains 3 or longer when one of
> the dependencies down the chain is broken.
>
> Do we have a way of writing tests for precomp?
>
>
>
>
> On Tue, May 17, 2016 at 4:23 AM mt1957 
> wrote:
>
>> # New Ticket Created by  mt1957
>> # Please include the string:  [perl #128156]
>> # in the subject line of all future correspondence about this issue.
>> # https://rt.perl.org/Ticket/Display.html?id=128156 >
>>
>>
>> Hi,
>>
>> I get the following error more often than before after some edits in my
>> source files.
>>
>> Missing or wrong version of dependency
>>
>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Wire.pm6
>> (MongoDB::Wire)' (from
>>
>> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Cursor.pm6
>> (MongoDB::Cursor)'
>>
>> A remedy to this is to touch all source files in the library I work on
>> and than retry. I think that this should not happen, at least not that
>> often (I've seen it several times in about a week I think, twice this
>> evening, to give an idea).
>>
>> This is Rakudo version 2016.04-200-gad82657 built on MoarVM version
>> 2016.04-134-g9879233
>> implementing Perl 6.c.
>>
>> Greetings,
>> Marcel
>>
>

Re: [perl #128156] dependency errors

[Lloyd Fournier]

I've been getting something similar and I've managed to golf it.

mkdir lib;
echo 'class One { }; need Two;' > lib/One.pm6
echo 'class Two { }; need Three;' > lib/Two.pm6
echo '' > lib/Three.pm6
perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'
echo "changing file" && touch lib/Two.pm6 # Three.pm6 will also break
perl6 -Ilib -e 'need One; say (GLOBAL:::exists ?? "OK" !! "NOT OK")'

summary:  Precomp is broken for dependency chains 3 or longer when one of
the dependencies down the chain is broken.

Do we have a way of writing tests for precomp?




On Tue, May 17, 2016 at 4:23 AM mt1957  wrote:

> # New Ticket Created by  mt1957
> # Please include the string:  [perl #128156]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128156 >
>
>
> Hi,
>
> I get the following error more often than before after some edits in my
> source files.
>
> Missing or wrong version of dependency
>
> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Wire.pm6
> (MongoDB::Wire)' (from
>
> '/home/marcel/Languages/Perl6/Projects/mongo-perl6-driver/lib/MongoDB/Cursor.pm6
> (MongoDB::Cursor)'
>
> A remedy to this is to touch all source files in the library I work on
> and than retry. I think that this should not happen, at least not that
> often (I've seen it several times in about a week I think, twice this
> evening, to give an idea).
>
> This is Rakudo version 2016.04-200-gad82657 built on MoarVM version
> 2016.04-134-g9879233
> implementing Perl 6.c.
>
> Greetings,
> Marcel
>

Re: [perl #128090] [RFC] Easy Way to Export Only Specific Symbols At Compile Time

[Lloyd Fournier]

Something like this has also passed through my head.

What about use Test :ALL<&is &ok> or use Test :SOME-TAG<&foo &bar>.

so you can filter out what you want with arguments to the tag. This seems
to be better and more backwards-compy because with current rakudo use Test
:ALL<&is &ok> will still work (it will just do a normal :ALL import).

Zoffix++ for bringing this up.

also, I think that require could be adapted to work like this. Right now
require can only import from DEFAULT which seems like a needless
restriction (the design docs seem a little confused on this point).

require Test <&is &ok>, :SOME-TAG<&foo &bar>;

I think it's a good feature and importing would be much more consistent.

LL


On Sat, May 7, 2016 at 11:12 AM Zoffix Znet 
wrote:

> # New Ticket Created by  Zoffix Znet
> # Please include the string:  [perl #128090]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128090 >
>
>
> Currently, there seems to be no easy way to import only specific symbols
> from a module *at compile time*.
>
> For example, if I want to use a module that exports a whole ton of
> functions but I only one just one, I have to write something complicated
> like this:
>
> need Test;
> my &is := &Test::EXPORT::DEFAULT::is;
>
> This difficulty will result in many programmers trashing their namespaces
> out of convenience, resulting in hard-to-find bugs, especially when newer
> version of `use`d module introduces new subs.
>
> I propose we create another reserved import tag :SYM that will take a list
> of SYMbols we want to import, eg:
>
> use Test :SYM<&is &ok>;
>
> Although I'm ignorant of the implementation of the :ALL tag, I'd think
> implementing :SYM would be similar (you'd just grep for wanted symbols).
>
> Relevant IRC conversation:
> http://irclog.perlgeek.de/perl6/2016-05-07#i_12446098
>

Re: [perl #122709] [PERF] await Promise in different thread

[Lloyd Fournier]

It works now!

whoever fixed it++. Close this! (and #125758).

On Mon, May 2, 2016 at 11:34 PM Will Coleda via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Wed Apr 27 03:02:14 2016, lloyd.fo...@gmail.com wrote:
> > Now I'm at home I tried it on my Mac,  I can confirm that:
> >
> > perl6 -e 'my $waiter = Proc::Async.new(:path, :args > World>).start; await start { await $waiter }'
> >
> > prints Hello World and then hangs forever.
> >
> > On Wed, Apr 27, 2016 at 2:58 PM Lloyd Fournier 
> > wrote:
> >
> > > Not sure if it's relevant here but last time I checked there is an
> issues
> > > with await and Proc::Async on Mac.
> > >
> > > RT #125758 for example which looks similar to this.
> > > On Wed, 27 Apr 2016 at 7:08 AM, Will Coleda via RT <
> > > perl6-bugs-follo...@perl.org> wrote:
> > >
> > >> On Fri Sep 05 14:44:06 2014, elizabeth wrote:
> > >> > (since leont has been so busy with other stuff, I thought to report
> > >> > the problem he found)
> > >> >
> > >> > 12:11   * leont suspects he's observing Promise.allof spinlocking or
> > >> > some such. 100% CPU usage, but no input is coming in :-/
> > >> > 12:19   lizmat  leont: could you gist that ?
> > >> > 12:22   leont   Would need to reduce it first, but sure
> > >> > 13:14   leont   My spinlock seems to have gone away when I await()ed
> > >> > in the same thread that created the Proc::Async…
> > >> > 13:16   lizmat  leont: interesting datapoint  :-)
> > >> > 13:16   wonder what jnthn would want to say about that  :-)
> > >> > 13:22   leont   perl6 -e 'my $waiter =
> > >> > Proc::Async.new(:path($*EXECUTABLE), :args(["helper.pl"])).start;
> > >> > await start { await $waiter };'
> > >> > 13:23   Let's make that easier: perl6 -e 'my $waiter =
> > >> > Proc::Async.new(:path("echo"), :args()).start; await
> > >> > start { await $waiter };'
> > >> > 13:29   moritz  leont++ # golfing
> > >> > 13:30   leont: could you please submit that to
> > >> > rakudobugperl.org?
> > >> > 13:30   leont   Sure
> > >>
> > >> This seems to work with no issue here. Is this ticket closable?
> > >>
> > >> $ perl6 -e 'my $waiter = Proc::Async.new(:path("echo"), :args( > >> World>)).start; await start { await $waiter };'
> > >> Hello World
> > >>
> > >> --
> > >> Will "Coke" Coleda
> > >>
> > >
>
> Can you include the output of sw_vers and perl6 --version ?
>
> --
> Will "Coke" Coleda
>

Re: [perl #128022] [BUG] Impossible to call Grammar.parse inside the Grammar's action class (with or without actions)

[Lloyd Fournier]

I took a look at this. I don't think it's a bug -- but definitely a LTA
error. It's happening because $/ is a parameter and by default parameters
are readonly. So when you call .parsefile it tries to set $/ but it can't
because it's readonly.

You could do method include($/ is copy) { }  # or just change it from
$/ to something else

or wrap the invocation of .parsefile in a block with a writable $/.

{
my $/;
my InclusiveActions $actions .= new;
make Inclusive.parsefile($filename, :$actions).made;
}

The error should be improved.


On Sat, Apr 30, 2016 at 4:14 AM Andy Weidenbaum <
perl6-bugs-follo...@perl.org> wrote:

> # New Ticket Created by  Andy Weidenbaum
> # Please include the string:  [perl #128022]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=128022 >
>
>
> Consider an HTML templating language with `include` directives similar to
> Haml/Jade/Pug. It is useful in these cases to, inside the grammar's
> Actions.pm, call Grammar.parse on any `include`d files. This is currently
> impossible to do. I golfed it as best I could in inclusive.p6.

Re: [perl #122709] [PERF] await Promise in different thread

[Lloyd Fournier]

Now I'm at home I tried it on my Mac,  I can confirm that:

perl6 -e 'my $waiter = Proc::Async.new(:path, :args).start; await start { await $waiter }'

prints Hello World and then hangs forever.

On Wed, Apr 27, 2016 at 2:58 PM Lloyd Fournier 
wrote:

> Not sure if it's relevant here but last time I checked there is an issues
> with await and Proc::Async on Mac.
>
> RT #125758 for example which looks similar to this.
> On Wed, 27 Apr 2016 at 7:08 AM, Will Coleda via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> On Fri Sep 05 14:44:06 2014, elizabeth wrote:
>> > (since leont has been so busy with other stuff, I thought to report
>> > the problem he found)
>> >
>> > 12:11   * leont suspects he's observing Promise.allof spinlocking or
>> > some such. 100% CPU usage, but no input is coming in :-/
>> > 12:19   lizmat  leont: could you gist that ?
>> > 12:22   leont   Would need to reduce it first, but sure
>> > 13:14   leont   My spinlock seems to have gone away when I await()ed
>> > in the same thread that created the Proc::Async…
>> > 13:16   lizmat  leont: interesting datapoint  :-)
>> > 13:16   wonder what jnthn would want to say about that  :-)
>> > 13:22   leont   perl6 -e 'my $waiter =
>> > Proc::Async.new(:path($*EXECUTABLE), :args(["helper.pl"])).start;
>> > await start { await $waiter };'
>> > 13:23   Let's make that easier: perl6 -e 'my $waiter =
>> > Proc::Async.new(:path("echo"), :args()).start; await
>> > start { await $waiter };'
>> > 13:29   moritz  leont++ # golfing
>> > 13:30   leont: could you please submit that to
>> > rakudobugperl.org?
>> > 13:30   leont   Sure
>>
>> This seems to work with no issue here. Is this ticket closable?
>>
>> $ perl6 -e 'my $waiter = Proc::Async.new(:path("echo"), :args(> World>)).start; await start { await $waiter };'
>> Hello World
>>
>> --
>> Will "Coke" Coleda
>>
>