[perl #127293] DOC INIT { use Module; } fails if Module is not installed, even if --doc is not used

[via RT]

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


For example:

DOC INIT {
  use Pod::EOD;
}

If Pod::EOD is not installed, compilation of this code will fail, even if --doc 
is not used on the command line.  On one hand, S26 implies that code inside of 
DOC INIT, DOC CHECK, and DOC BEGIN blocks is not executed if --doc is not used; 
on the other, use Module; statements are normally executed as soon as they're 
parsed.

Re: Needed: Rakudo Star with 6.c Christmas Perl 6 release

[Brandon Allbery]

On Sat, Jan 16, 2016 at 1:40 PM, James E Keenan  wrote:

> Is there a timeline for the release of a Rakudo Star with 6.c?
>

I don't think there is a specific timeline, but given the rakudo bug fixes
since 6.c (in particular with CompUnitRepo, which would have made it
difficult to install the modules one expects in Star) it was correct to
delay a Star release. Hopefully it'll happen in the next few days.

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

Needed: Rakudo Star with 6.c Christmas Perl 6 release

[James E Keenan]

Today, I posted on the ny.pm mailing list an announcement that I will 
attempt to organize a Perl 6 Beginners study group in New York City.


I have been advised that for an introductory-level group, the Rakudo 
Star release would be the way to go.  However, when I went here:


  http://rakudo.org/how-to-get-rakudo/

... I read this:

"NOTE: the Rakudo Star with 6.c Christmas Perl 6 release is not yet
 available. Check back soon or try one of the older versions."

This is what, back in the day, we used to call a 'bummer'.  We have 
people -- including non-Perl programmers -- excited about Perl 6 -- but 
we don't have the easy on-ramp.


Is there a timeline for the release of a Rakudo Star with 6.c?

Thank you very much.
Jim Keenan

Re: Needed: Rakudo Star with 6.c Christmas Perl 6 release

[Brock Wilcox]

I think folks were shooting for sometime-this-month.
On Jan 16, 2016 1:40 PM, "James E Keenan"  wrote:

> Today, I posted on the ny.pm mailing list an announcement that I will
> attempt to organize a Perl 6 Beginners study group in New York City.
>
> I have been advised that for an introductory-level group, the Rakudo Star
> release would be the way to go.  However, when I went here:
>
>   http://rakudo.org/how-to-get-rakudo/
>
> ... I read this:
>
> "NOTE: the Rakudo Star with 6.c Christmas Perl 6 release is not yet
>  available. Check back soon or try one of the older versions."
>
> This is what, back in the day, we used to call a 'bummer'.  We have people
> -- including non-Perl programmers -- excited about Perl 6 -- but we don't
> have the easy on-ramp.
>
> Is there a timeline for the release of a Rakudo Star with 6.c?
>
> Thank you very much.
> Jim Keenan
>

Workaround for Perl 5's __DATA__

[Tom Browder]

I have tried this in my Perl 6 code (v6.c):

=begin DATA
blah
blah2
=end DATA

Then:

for $=DATA.lines -> $line {
  # process a line
}

but I get this message:

Pod variable @=DATA not yet implemented. Sorry.

Is there any workaround for this other than putting the data in an array?

Thanks.

Best regards,

-Tom

[perl #127291] [BUG] temp fails to set hashes with non-string key type constraints

[via RT]

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


The following code:

my %h{Pair};
%h{a => 1} = 2;
temp %h = %h.clone;

should succeed. However, it fails with the following error:

> Type check failed in binding key; expected Pair but got Str

Rakudo version:

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

[perl #127294] Using POD directives in declarative blocks (like I<...>) doesn't work

[via RT]

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


For example:

#| Here I am
sub foo() {}

say(); # Here I am

Re: [perl #127294] Using POD directives in declarative blocks (like I<...>) doesn't work

[Lloyd Fournier]

There are now three of these XD.

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

FYI this is really difficult to implement with pod in its present state.
IMO We need POD as another language approach to do this properly:
https://github.com/ShimmerFairy/SUPERNOVA

On Sun, Jan 17, 2016 at 2:25 PM Rob Hoelz 
wrote:

> # New Ticket Created by  Rob Hoelz
> # Please include the string:  [perl #127294]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127294 >
>
>
> For example:
>
> #| Here I am
> sub foo() {}
>
> say(); # Here I am
>

Re: [perl #126654] [POD] Formatting codes does not work inside declarator blocks

[Lloyd Fournier]

I have also been down this path. The one line version is doable as you
suggested but the #|{  } version is harder because you need to nibble
in a sublanguage or do manual balanced text processing, which is why the
original author never implemented it I'm guessing.

The trick is getting:
#|{
 docs for sub { } are in here
}
to parse properly. I would love it if you could do it!


On Sun, Jan 17, 2016 at 4:52 PM Rob Hoelz via RT <
perl6-bugs-follo...@perl.org> wrote:

> I haven't looked at SUPERNOVA much, but I think this should actually be
> pretty simple to fix.  The comment:sym<#|> token and friends need to be
> updated to use the pod_content rule.  If I have enough time this week, I
> may end up doing this.
>
> On 2016-01-16 20:36:48, lloyd.fo...@gmail.com wrote:
> > There are now three of these XD.
> >
> > https://rt.perl.org/Public/Bug/Display.html?id=126954
> > https://rt.perl.org/Public/Bug/Display.html?id=126654
> >
> > FYI this is really difficult to implement with pod in its present state.
> > IMO We need POD as another language approach to do this properly:
> > https://github.com/ShimmerFairy/SUPERNOVA
> >
> > On Sun, Jan 17, 2016 at 2:25 PM Rob Hoelz 
> > wrote:
> >
> > > # New Ticket Created by  Rob Hoelz
> > > # Please include the string:  [perl #127294]
> > > # in the subject line of all future correspondence about this issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=127294 >
> > >
> > >
> > > For example:
> > >
> > > #| Here I am
> > > sub foo() {}
> > >
> > > say(); # Here I am
> > >
>
>
>
>

Re: [perl #126654] [POD] Formatting codes does not work inside declarator blocks

[Lloyd Fournier]

Forgot, the tricky one is really:

#|{ docs for sub { } are in here }  sub foo { }

^^ That should be fine and parses properly now. IMO just making the one
line work is also acceptable for now I'd say if you can't achieve both.

On Sun, Jan 17, 2016 at 4:58 PM Lloyd Fournier 
wrote:

> I have also been down this path. The one line version is doable as you
> suggested but the #|{  } version is harder because you need to nibble
> in a sublanguage or do manual balanced text processing, which is why the
> original author never implemented it I'm guessing.
>
> The trick is getting:
> #|{
>  docs for sub { } are in here
> }
> to parse properly. I would love it if you could do it!
>
>
> On Sun, Jan 17, 2016 at 4:52 PM Rob Hoelz via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> I haven't looked at SUPERNOVA much, but I think this should actually be
>> pretty simple to fix.  The comment:sym<#|> token and friends need to be
>> updated to use the pod_content rule.  If I have enough time this week, I
>> may end up doing this.
>>
>> On 2016-01-16 20:36:48, lloyd.fo...@gmail.com wrote:
>> > There are now three of these XD.
>> >
>> > https://rt.perl.org/Public/Bug/Display.html?id=126954
>> > https://rt.perl.org/Public/Bug/Display.html?id=126654
>> >
>> > FYI this is really difficult to implement with pod in its present state.
>> > IMO We need POD as another language approach to do this properly:
>> > https://github.com/ShimmerFairy/SUPERNOVA
>> >
>> > On Sun, Jan 17, 2016 at 2:25 PM Rob Hoelz > >
>> > wrote:
>> >
>> > > # New Ticket Created by  Rob Hoelz
>> > > # Please include the string:  [perl #127294]
>> > > # in the subject line of all future correspondence about this issue.
>> > > # https://rt.perl.org/Ticket/Display.html?id=127294 >
>> > >
>> > >
>> > > For example:
>> > >
>> > > #| Here I am
>> > > sub foo() {}
>> > >
>> > > say(); # Here I am
>> > >
>>
>>
>>
>>

[perl #127289] stringyfication on type capture in signatures returns the literal of the type capture instead of the resolved type named

[via RT]

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


class C {};
sub outer(::T $c){
 sub (T){ dd &?ROUTINE.signature.params[0], T === C, T.new }
};
my $inner = outer(C); $inner(C.new);

# OUTPUT«T $␤Bool::True␤C.new␤»
# expected:
# OUTPUT«C $␤Bool::True␤C.new

# The typecheck on function call does work. It's merely a stringy problem.

$inner(W.new);

# OUTPUT«Type check failed in binding ; 
# expected C but got W␤  in sub  at /tmp/uEPuZVCl2m line 1␤  in block 
#  at /tmp/uEPuZVCl2m line 1␤␤»