Re: Teaching Rakudo the tricks of Perl 5's regex optimiser

[Patrick R. Michaud]

FWIW, at one time there was discussion that "" and "" 
are actually keywords and not typical method calls that can be overridden,
precisely so optimizations can be made.  They're that important to
efficient running of the regexes.


I'm not sure that a formal decision was ever made on this, however.
(I'd be okay with declaring them as keywords that cannot be overridden.)

Pm

On Tue, Aug 13, 2019 at 05:01:06PM +0200, Timo Paulssen wrote:
> 
> >     use v6;
> >     'abcd' ~~ / . <.before( /c/ )> .  / # "bc"
> >     'abcd' ~~ / . <.before   c   > .  / # "bc" # (exactly identical)
> >
> > A person could change the code in the `before` method to have it do
> > something different
> 
> 
> At least at the moment, that's not 100% accurate (only by virtue of
> leaving out a piece):
> 
> timo@schmand ~> perl6 -e 'grammar test { regex before($re) { { say "yo"
> } }; regex TOP { <.before "hi"> } }; test.parse("hi")'
> yo
> Too few positionals passed; expected 2 arguments but got 1
>   in regex before at -e line 1
>   in regex TOP at -e line 1
>   in block  at -e line 1
> 
> timo@schmand ~ [1]> perl6 -e 'grammar test { regex before($re) { { say
> "yo" } }; regex TOP {  } }; test.parse("hi")'
> yo
> Too few positionals passed; expected 2 arguments but got 1
>   in regex before at -e line 1
>   in regex TOP at -e line 1
>   in block  at -e line 1
> 
> timo@schmand ~ [1]> perl6 -e 'grammar test { regex before($re) { { say
> "yo" } }; regex TOP {  } }; test.parse("hi")'
> 
> As you can see, using  gives you the "real" lookahead assertion.
> 
> I'm not sure if that's part of the language yet, but should probably
> made to be.
> 
> 
> This will allow more optimization efforts.

Re: [perl #133541] Grammer bug vs

[Patrick R. Michaud via RT]

The issue doesn't seem to be the underscore, because I get the same result even 
when converting the underscore into a letter ('b'):

$ cat gentb.p6 
grammar G0 {
token TOP {|.*}
regex rport { }
rule ruport { }
#token type {+}
token type {+}
}

grammar G1 {
token TOP {|.*}
regex rport { }
rule ruport { }
token type {+}
#token type {+}
}
my $str="scbin bar";
say "===  Example==";
say G0.parse($str);
say "===  Example==";
say G1.parse($str);

$ perl6 gentb.p6
===  Example==
Nil
===  Example==
｢scbin bar｣
 ruport => ｢scbin｣
  type => ｢scbin｣
   alpha => ｢s｣
   alpha => ｢c｣
   alpha => ｢b｣
   alpha => ｢i｣
   alpha => ｢n｣
$ 


On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> Are you sure about that?  Underscore has been part of the specs (synopses)
> for  for at least 10 years, probably longer.
> 
>  >  "_" ~~ //
> ｢_｣
>  alpha => ｢_｣
> 
> On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery  wrote:
> 
> > "_" is not an alphabetic character. It's allowed in "alnum" because that
> > is by intent what is \w in other regex implementations, which includes "_".
> >
> > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal 
> > wrote:
> >
> >> # New Ticket Created by  Vijayvithal
> >> # Please include the string:  [perl #133541]
> >> # in the subject line of all future correspondence about this issue.
> >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> >>
> >>
> >> In the attached code, the only difference between the Grammars G0 and G1
> >> is the defination of token 'type' it is defined as  in one case
> >> and as  in another.
> >>
> >> Since the string being matched is 'sc_in' both the alpha and alnum
> >> tokens should have captured it. But we see the following result on
> >> execution
> >>
> >> ===  Example==
> >> Nil
> >> ===  Example==
> >> ｢sc_in bar｣
> >> ruport => ｢sc_in｣
> >> type => ｢sc_in｣
> >> alpha => ｢s｣
> >> alpha => ｢c｣
> >> alpha => ｢_｣
> >> alpha => ｢i｣
> >> alpha => ｢n｣
> >>
> >>
> >> Perl Version is
> >>
> >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> >> implementing Perl 6.c.
> >>
> >>
> >>
> >> --
> >> Vijayvithal
> >> Dyumnin Semiconductors
> >>
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com
> >

Re: [perl #133541] Grammer bug vs

[Patrick R. Michaud]

The issue doesn't seem to be the underscore, because I get the same result even 
when converting the underscore into a letter ('b'):

$ cat gentb.p6 
grammar G0 {
token TOP {|.*}
regex rport { }
rule ruport { }
#token type {+}
token type {+}
}

grammar G1 {
token TOP {|.*}
regex rport { }
rule ruport { }
token type {+}
#token type {+}
}
my $str="scbin bar";
say "===  Example==";
say G0.parse($str);
say "===  Example==";
say G1.parse($str);

$ perl6 gentb.p6
===  Example==
Nil
===  Example==
｢scbin bar｣
 ruport => ｢scbin｣
  type => ｢scbin｣
   alpha => ｢s｣
   alpha => ｢c｣
   alpha => ｢b｣
   alpha => ｢i｣
   alpha => ｢n｣
$ 


On Fri, Sep 28, 2018 at 02:26:41AM -0700, Brent Laabs wrote:
> Are you sure about that?  Underscore has been part of the specs (synopses)
> for  for at least 10 years, probably longer.
> 
>  >  "_" ~~ //
> ｢_｣
>  alpha => ｢_｣
> 
> On Thu, Sep 27, 2018 at 7:52 PM Brandon Allbery  wrote:
> 
> > "_" is not an alphabetic character. It's allowed in "alnum" because that
> > is by intent what is \w in other regex implementations, which includes "_".
> >
> > On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal 
> > wrote:
> >
> >> # New Ticket Created by  Vijayvithal
> >> # Please include the string:  [perl #133541]
> >> # in the subject line of all future correspondence about this issue.
> >> # https://rt.perl.org/Ticket/Display.html?id=133541 >
> >>
> >>
> >> In the attached code, the only difference between the Grammars G0 and G1
> >> is the defination of token 'type' it is defined as  in one case
> >> and as  in another.
> >>
> >> Since the string being matched is 'sc_in' both the alpha and alnum
> >> tokens should have captured it. But we see the following result on
> >> execution
> >>
> >> ===  Example==
> >> Nil
> >> ===  Example==
> >> ｢sc_in bar｣
> >> ruport => ｢sc_in｣
> >> type => ｢sc_in｣
> >> alpha => ｢s｣
> >> alpha => ｢c｣
> >> alpha => ｢_｣
> >> alpha => ｢i｣
> >> alpha => ｢n｣
> >>
> >>
> >> Perl Version is
> >>
> >> This is Rakudo Star version 2018.06 built on MoarVM version 2018.06
> >> implementing Perl 6.c.
> >>
> >>
> >>
> >> --
> >> Vijayvithal
> >> Dyumnin Semiconductors
> >>
> >
> >
> > --
> > brandon s allbery kf8nh
> > allber...@gmail.com
> >

Re: [perl #132066] [BUG] Code blocks cause backtracking fail in `|` alternation with ratcheting

[Patrick R. Michaud via RT]

On Mon, Sep 11, 2017 at 09:48:01AM -0700, Dan Zwell wrote:
> 
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
> 
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil

Isn't the whole point of :ratchet to turn off backtracking...?  From S05 (which 
I know isn't official anymore but it describes what :ratchet does or was 
intended to do):

   "The new :r or :ratchet modifier causes this regex to not backtrack by 
default."

It looks to me like the two above examples are working exactly as 
designed/intended.

Pm

Re: [perl #132066] [BUG] Code blocks cause backtracking fail in `|` alternation with ratcheting

[Patrick R. Michaud]

On Mon, Sep 11, 2017 at 09:48:01AM -0700, Dan Zwell wrote:
> 
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
> 
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil

Isn't the whole point of :ratchet to turn off backtracking...?  From S05 (which 
I know isn't official anymore but it describes what :ratchet does or was 
intended to do):

   "The new :r or :ratchet modifier causes this regex to not backtrack by 
default."

It looks to me like the two above examples are working exactly as 
designed/intended.

Pm

Re: Verifiable Releases/The Build System is Ridiculous

[Patrick R. Michaud]

The details of how to use the star GitHub repository are in 
tools/star/release_guide.pod .

You're entirely welcome to create a bundling that has a better build system 
than what Rakudo Star uses -- indeed, Rakudo Star has always been intended to 
be just one of many possible bundlings of Rakudo and useful modules.  Even if 
you just create a repo to demonstrate a better way of organizing modules, 
that'd be helpful.

The earliest versions of the Rakudo Star build system started out by trying to 
use Git submodules to manage packages, but it quickly proved to be unwieldy and 
almost impossible to understand and maintain.  Perhaps the submodule ecosystem 
has changed since then, though.

Pm


On Thu, Jul 27, 2017 at 03:13:19AM -0500, R0b0t1 wrote:
> Are there any releases signed by the developers? The official releases
> located at https://rakudo.perl6.org/downloads/star/ do not seem to
> have signatures available.
> 
> As a stopgap measure I attempted to clone
> https://github.com/rakudo/star and run Configure.pl. I felt it strange
> that it warned me against using the code in the repository as cloned
> from the repository (why does the repository exist?) but continued
> with --force, only to find out that some of the folders in the
> directory structure need to be initialized. A mailing list posting was
> found detailing how to continue
> (http://www.nntp.perl.org/group/perl.perl6.compiler/2013/05/msg8915.html)
> and the steps were followed. Unfortunately, the nqp package download
> failed with error 404, which made me see the following command was
> part of the preparation script:
> 
> >wget --no-check-certificate 
> >https://rakudo.perl6.org/downloads/nqp/nqp-2017.07-9-gc0abee7.tar.gz -O 
> >src/nqp-2017.07-9-gc0abee7.tar.gz
> 
> I have no words. Can anyone justify this choice?
> 
> Are there any signed releases, or do I have to do the equivalent of curl|sudo?
> 
> 
> What is being done should actually be done with Git submodules, or the
> more recent feature, subtrees. There is no reason for the releases to
> be prepared in this way. What has been created is a very inflexible
> package management system. If what you want is a package management
> system, then I would suggest adapting Gentoo's portage to the
> project's needs, as KDE seems to have done with their Craft build
> system. However what the project needs is version control that will
> handle dependencies.
> 
> Git's submodules fit perfectly because they pin a directory to a
> branch which is exactly what is being done here, but it is integrated
> with Git and can use existing authentication and verification
> mechanisms (HTTPS, SSH, GPG). There are various articles which try to
> paint submodules as unsuitable for most uses but I hope it is easy to
> see that what they do is exactly what is desired in this instance.
> 
> If submodules do not seem suitable, there are subtrees, but these blur
> the lines between projects. That might be okay, but they are slightly
> more complicated to use.
> 
> R0b0t1.

Re: [perl #131708] [BUILD]. Rakudo Star build instructions incomplete

[Patrick R. Michaud via RT]

On Wed, Jul 05, 2017 at 06:10:42PM -0700, Will Coleda via RT wrote:
> On Wed, 05 Jul 2017 09:16:44 -0700, tbrowder wrote:
> > Given this invocation for a new installation of rakudo:
> > 
> >   perl Configure.pl  --backend=moar --gen-moar --prefix=/some/dir
> > 
> > /some/dir needs to exist and belong to the user attempting the
> > installation.  That usually forces the user to be root just to configure
> > and build rakudo.  Then the build directory is polluted with root-owned
> > files.
> > [...]
> > Until that problem is solved, the installation instructions need to detail
> > the current requirements of an installation outside the build directory.
> 
> This is the wrong queue for this ticket; please re-open at github's 
> rakudo/star queue.

Perhaps it's also worth mentioning that variations of this issue (build with 
one user and install with another) already exist in Rakudo Star's issue queue:

https://github.com/rakudo/star/issues/23
https://github.com/rakudo/star/issues/65
https://github.com/rakudo/star/issues/70

Pm

Re: [perl #131708] [BUILD]. Rakudo Star build instructions incomplete

[Patrick R. Michaud]

On Wed, Jul 05, 2017 at 06:10:42PM -0700, Will Coleda via RT wrote:
> On Wed, 05 Jul 2017 09:16:44 -0700, tbrowder wrote:
> > Given this invocation for a new installation of rakudo:
> > 
> >   perl Configure.pl  --backend=moar --gen-moar --prefix=/some/dir
> > 
> > /some/dir needs to exist and belong to the user attempting the
> > installation.  That usually forces the user to be root just to configure
> > and build rakudo.  Then the build directory is polluted with root-owned
> > files.
> > [...]
> > Until that problem is solved, the installation instructions need to detail
> > the current requirements of an installation outside the build directory.
> 
> This is the wrong queue for this ticket; please re-open at github's 
> rakudo/star queue.

Perhaps it's also worth mentioning that variations of this issue (build with 
one user and install with another) already exist in Rakudo Star's issue queue:

https://github.com/rakudo/star/issues/23
https://github.com/rakudo/star/issues/65
https://github.com/rakudo/star/issues/70

Pm

Re: [perl #129829] .pick on large ranges returns binary-sparse result

[Patrick R. Michaud]

On Fri, Oct 07, 2016 at 12:18:43PM -0700, Aaron Sherman wrote:
> [15:12]  m: say ((2**80) ..^ (2**81)).pick.base(2)
> [15:12] <+camelia> rakudo-moar 605f27:
> OUTPUT«100011101100100110010001010110101101010011001␤»
> 
> The middle part is always a large number of zeros, but it's my
> understanding that it should be a more uniform and continuous range of
> results.

Awesome catch!  The current implementation of Range.pick() is based on
Range.roll(), which uses nqp::rand_I() to choose a random value from
an integer range.

I'm guessing nqp::rand_I() is returning a 32-bit number, and so Range.pick/
Range.roll are actually only returning values from 2**80 to 2**80+2**32-1 .

Pm

Re: Best way to get a PCRE6 on the JVM?

[Patrick R. Michaud]

On Thu, Sep 29, 2016 at 01:30:29PM +0200, Joachim Durchholz wrote:
> Can you tell me where the sources for the regex engine live? At the
> detailed-technical-spec level, I found S05, and I can find the NQP spec, but
> I don't know my way around the interpreter sources yet.

The regex engine lives in src/QRegex of the nqp repository.
https://github.com/perl6/nqp/tree/master/src/QRegex

> My hope is that it's possible to use the JVM port of Rakudo to compile the
> regex engine to JVM bytecode.

I'm not entirely familiar with Rakudo's JVM implementation, but I
believe that the regex engine portion (supplied by NQP) is 
_already_ in JVM bytecode.

Unlike PCRE, the NQP regex library isn't a C-based library that
is magically linked into the runtime engine with glue. 
NQP compiles the regex engine (and many of NQP's other components)
directly to the target VM's environment.

Pm

Re: Best way to get a PCRE6 on the JVM?

[Patrick R. Michaud]

A simpler approach might be to build an NQP that runs on the JVM, and
find a way to call into it.  (The Perl 6 regular expression engine is
written in NQP.)

Pm

On Wed, Sep 28, 2016 at 09:21:50AM -0400, Will Coleda wrote:
> To start with, there isn't a PCRE6.
> 
> If you want, more generically, to be able to use Perl 6 Regular
> Expressions in Java, you can build a rakudo that runs (with reduced
> functionality) on the JVM.
> 
> I'm not sure there's a way at this point to call into the Perl 6 code
> from arbitrary Java code, however.
> 
> On Wed, Sep 28, 2016 at 6:10 AM, Toolforger  wrote:
> > Hi all,
> >
> > title says it all: I have a use case for a Perl6 PCRE on the JVM.
> >
> > Sorry for wasting your time if such a thing already exists; if no, I'd like
> > to discuss strategies how to best do that.
> >
> > Thanks in advance!
> > Jo
> 
> 
> 
> -- 
> Will "Coke" Coleda

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

[Patrick R. Michaud via RT]

On Sat, Sep 24, 2016 at 07:37:52AM +, Lloyd Fournier wrote:
> 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.

You're correct that .WHAT is a special case.  From S12, "Introspection":

   These should all be considered built-in language primitives, 
   not true operators or methods, even if a given implementation 
   happens to implement one or more of them that way.

I suppose it's possible that *.WHAT should generate a WhateverCode object...
but I'm a little disinclined to that.  A bit later S12 continues:

   In general, use of these uppercased accessors in ordinary code
   should be a red flag that Something Very Strange is going on.
   (Hence the allcaps.)  Most code should use Perl 6's operators that
   make use of this information implicitly.  For instance, instead of

   $obj.WHAT === Dog
   ...

   you usually just want:

   $obj ~~ Dog

So I'd say this isn't actually a bug.

Pm

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

[Patrick R. Michaud]

On Sat, Sep 24, 2016 at 07:37:52AM +, Lloyd Fournier wrote:
> 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.

You're correct that .WHAT is a special case.  From S12, "Introspection":

   These should all be considered built-in language primitives, 
   not true operators or methods, even if a given implementation 
   happens to implement one or more of them that way.

I suppose it's possible that *.WHAT should generate a WhateverCode object...
but I'm a little disinclined to that.  A bit later S12 continues:

   In general, use of these uppercased accessors in ordinary code
   should be a red flag that Something Very Strange is going on.
   (Hence the allcaps.)  Most code should use Perl 6's operators that
   make use of this information implicitly.  For instance, instead of

   $obj.WHAT === Dog
   ...

   you usually just want:

   $obj ~~ Dog

So I'd say this isn't actually a bug.

Pm

Re: [perl #129271] [REGEX] Captures from interpolated variables do not capture

[Patrick R. Michaud]

On Wed, Sep 14, 2016 at 05:10:55PM -0700, Zoffix Znet wrote:
>  m: my $input = '(\d\d\d)'; my $m = 'a 123' ~~ /<$input>/; dd 
> [$m.list];
>  rakudo-moar 2c95f7: OUTPUT«[]␤»
> 
> 
> Expected results: output is the same, as the $input contains a capture that 
> should capture stuff when interpolated.

<$input> is non-capturing, so even though it contains a $0 capture, its result
won't be held by the outermost Match object.

Rewrite to 

Re: [perl #129131] [RFC] Make .. a numeric operator, please (.say for ‘42’..‘51’)

[Patrick R. Michaud]

On Tue, Aug 30, 2016 at 07:00:43PM -0700, Zoffix Znet via RT wrote:
> So far I think the original RFC to make .. a numeric operator is out. 
> There's still an issue with .. not using .succ on strings. Does anyone 
> know why that is the case? The templating example I presented is still 
> valid with the pure .succ behaviour.

As a historical datapoint, there *was* a time when .. explicitly used 
.succ on strings and other non-numeric types.  I know it was implemented 
that way in Rakudo -- I don't know why/when that behavior changed.  See,
for example, S03:3550 (and there are other examples sprinkled
throughout S03).

Pm

Re: [perl #122346] [@LARRY] "nom regression" behavior of lexicals/invoking sub before they are defined changed

[Patrick R. Michaud]

On Tue, Aug 23, 2016 at 10:28:26AM -0700, Will Coleda via RT wrote:
> > Where the expectation is that the first call to the foo will return an
> > undefined value; in nom, it returns 0.
> 
> This behavior has been in place for years now, since before Christmas.
> 
> Tagging [@LARRY] to get a ruling on whether the test is any good.

The relevant (offending?) line in the source code is 
https://github.com/rakudo/rakudo/blob/nom/src/core/Any.pm#L444 :

   multi postfix:<++>(Mu:U $a is rw) { $a = 1; 0 }

Pm

Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks

[Patrick R. Michaud]

On Thu, Aug 18, 2016 at 10:38:57AM -0400, Brandon Allbery wrote:
> On Thu, Aug 18, 2016 at 9:13 AM, Claudio 
> wrote:
> 
> > Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for
> > now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and
> > CHECK blocks as documented), this is a security concern for external code.
> 
> The problem is that you probably can't parse the code successfully if you
> can't run BEGIN blocks. While this is currently less true of perl 6 code in
> the wild, it's actually even worse in potential than perl 5's ability to
> mutate its parser because a module can implement entire new languages.

Also, many things in Perl 6 get executed at BEGIN time even if they're 
not explicitly in a BEGIN block.  Constant and class declarations come 
to mind, but I'm sure there are more.

For example:

  $ cat xyz.p6
  use v6;
  
  say "1: mainline";
  constant $a = say "2: constant";
  BEGIN { say "3: BEGIN"; }
  
  $ ./perl6 xyz.p6
  2: constant
  3: BEGIN
  1: mainline

Pm

Re: [perl #128842] [BUG] := inconsistent semantics

[Patrick R. Michaud]

On Thu, Aug 04, 2016 at 09:54:54PM +0100, Zefram wrote:
> Patrick R. Michaud wrote:
> >So are you looking for...?
> 
> No.  I want a writable reference that I can pass around as a value,
> store in a data structure, and so on.  The Scalar object obtained by
> "$a.VAR" is clearly the thing to pass around as a value; I'm looking
> for the way to write through it.

"writable reference"  -->  "Scalar"

"store in a data structure"  -->  "bind using :="

I think that using := is the canonical way to do these sorts of operations:

> my $a = 123;
123
> my $b := $a;  $b = 5;  say $a;
5
> my @c;  @c[2] := $a;  $a = 5;  say @c[2];
5
> my %d;  %d := $a;  $a = 'abc';  say %d;
abc
> say "$a $b @c[2] %d";
abc abc abc abc
> $a = 4; say "$a $b @c[2] %d"
4 4 4 4

More generally -- when I last checked Perl 6 doesn't really have "references" 
in the same style as Perl 5 -- i.e., objects that can be passed around and are 
magically transparent when you need them to be and opaque when you don't.  So 
far I think we've been able to use binding to do all of the things that Perl 5 
references allowed (but more cleanly and efficiently).

Pm

Re: [perl #128842] [BUG] := inconsistent semantics

[Patrick R. Michaud]

On Thu, Aug 04, 2016 at 09:36:18PM +0100, Zefram wrote:
> Yeah.  Let me try to make it clearer.  In the above situation, with
> a reference to $a's Scalar container in $b, I'd like to achieve what
> the assignment "$a = 5" would, but by an operation using $b and not
> directly mentioning $a.  The result should be that $b is unchanged
> (still referencing $a's container) and $a subsequently has the value 5.

So are you looking for...?

   my $a = 3;
   my $b := $a;# $b is bound to $a

   $b = 5; # Assign 5 to $b (which is also $a)
   say $a; # "5"

Pm

Re: [perl #128818] [BUG] sprintf %f bogus rounding

[Patrick R. Michaud]

On Tue, Aug 02, 2016 at 07:46:20PM +0100, Zefram wrote:
> > sprintf("%f", 2e0**70)
> 118059162071741000.00
> 
> >In particular, the true value is *not* always available,
> 
> By "true value" I meant the value represented in floating point.

My apologies, I did not catch this meaning of "true value" from
your posts.  You've correctly deduced that I've been referring to 
the mathematically pure value represented by the decimal literal in
source code, and not the value that results from its conversion to
floating point.

I agree that having sprintf("%f") automatically truncate with zeros
after 15 digits of precision is perhaps not the best approach here.
I think it should perhaps be available to at least 17 places, and
possibly even more in examples like 2**70.  But that's a language
specification call that someone outside of Rakudo probably needs
to make.

Pm

Re: [perl #128817] [BUG] Num.perl doesn't round-trip numeric value

[Patrick R. Michaud]

On Tue, Aug 02, 2016 at 07:32:56PM +0100, Zefram wrote:
> Patrick R. Michaud via RT wrote:
> >I don't know that we should expect .perl or any other operation on Num
> >values to be preserving more precision than that.
> 
> I'd expect .perl to preserve whatever precision is there.  Accurately
> representing the value, in a form understandable by .EVAL, is its
> raison d'etre.
> [...]

Okay.  I'm agreeable to say that .perl (and perhaps sprintf where 
appropriate) should add two more digits of precision to the strings 
they produce, to preserve the round-trippiness of the values being
represented.

> (1180591620717411303424e0).perl
1.18059162071741e+21
> (1.18059162071741e+21).Int # not enough precision
1180591620717409992704
> (1.180591620717411e+21).Int# still not enough
1180591620717411041280
> (1.1805916207174113e+21).Int   # okay, this works
1180591620717411303424

Pm

Re: [perl #128820] [BUG] == on Num literals produces bogus answer

[Patrick R. Michaud]

On Tue, Aug 02, 2016 at 10:55:34AM -0700, Zefram wrote:
> These literals work fine in other contexts:
> 
> > my $a = 1180591620717411303424e0
> 1.18059162071741e+21
> > my $b = 1180591620717409992704e0
> 1.18059162071741e+21
> > $a.Int
> 1180591620717411303424
> > $b.Int
> 1180591620717409992704
> > $a == $b
> False
> > $a === $b
> False

It's not universally true that Num literals like these "work fine in other 
contexts" -- the pair of literals in the example given "work" because they 
differ in the fifteenth decimal digit of precision.  This is within the 
acceptable norms for Num (floating point) precision.

Choosing a different pair of literal values that differ beyond the first 15 
digits of precision shows that things do not work fine in other contexts:

>  my $a = 1180591620717411303424e0
1.18059162071741e+21
>  my $b = 118059162071741133e0
1.18059162071741e+21
> $a.Int
1180591620717411303424
> $b.Int
1180591620717411303424
> $a == $b
True
> $a === $b
True

In short, it's "normal" (expected behavior) for mathematical errors to occur 
beyond 15 digits of precision in Num (floating point) values.

Pm

Re: [perl #128818] [BUG] sprintf %f bogus rounding

[Patrick R. Michaud]

On Tue, Aug 02, 2016 at 09:56:38AM -0700, Zefram wrote:
> > (1180591620717411303424.0e0).Int
> 1180591620717411303424
> > sprintf("%f", 1180591620717411303424.0e0)
> 118059162071741000.00
> 
> sprintf %f is not showing the true value of this Num, which it should.
> The .Int coercion is correct, and shows that the true value is actually
> available.

Nums hold only 15-17 digits of precision, so sprintf("%f")
likely has this one correct.

In particular, the true value is *not* always available, as illustrated by:

  > (1180591620717411303424.0e0).Int
  1180591620717411303424
  > (1180591620717411303434.0e0).Int
  1180591620717411303424

Pm

Re: Questions on using other "modules" in nqp

[Patrick R. Michaud]

My short answer would be that there's not a shortcut way in NQP
to avoid the fully-qualified sub names.  I'm doubtful that we want
to duplicate Perl 6's import mechanism into NQP.

Pm

On Fri, Jul 22, 2016 at 07:48:55AM -0500, Tom Browder wrote:
> ping
> 
> On Thu, Jul 7, 2016 at 7:49 AM, Tom Browder  wrote:
> > I have added a file "DebugPod.nqp" in the directory rakudo/src/Perl6
> > and want to use it for debugging other files in that directory.
> >
> > Following the format of the "Pod.nqp" file in that directory, I have
> > structured my new file this way:
> >
> >   Perl6::DebugPod {
> > our sub debug_rows($desc, @rows) {...}
> > our sub debug_array($desc, @arr) {...}
> > # etc.
> >   }
> >
> > In file "Pod.nqp" I have added at the top before the class declaration:
> >
> >   use Perl6::DebugPod;
> >
> > Inside "Pod.nqp" I currently (and successfully) call the debug
> > functions like this:
> >
> >   Perl6::DebugPod::debug_rows('after _rows', @rows);
> >
> > The main question I have is "is there any way to avoid having to use
> > the fully-qualified sub name on the external functions?"
> >
> > Thanks.
> >
> > Best regards,
> >
> > -Tom

Re: [perl #128587] [POD] need pod-to-man translator

[Patrick R. Michaud]

On Tue, Jul 12, 2016 at 08:48:59AM -0500, Tom Browder wrote:
> > If --help mentions a man page, it's probably sufficient to ship Rakudo
> > with an already-translated man page, rather than shipping the translator.
> 
>Very true--the voice of reason!
> 
>But shouldn't all the pod6-to-X translators live together and share
>lots of common code (such as ShimmerFairy's planned pod6 grammar)?

Sure, it's reasonable for pod6-to-X translators to live together; but Rakudo 
(compiler) isn't the place for that.  Better is to have the translators as 
modules, and then bundle them into a distribution like a Rakudo Star or the 
like.

Pm

Re: [perl #128587] [POD] need pod-to-man translator

[Patrick R. Michaud]

I think any pod2man translator program should be separate from Rakudo itself.

If --help mentions a man page, it's probably sufficient to ship Rakudo
with an already-translated man page, rather than shipping the translator.

Pm

On Tue, Jul 12, 2016 at 04:34:00AM -0500, Tom Browder wrote:
>On Monday, July 11, 2016, Will Coleda via RT
><[1]bugs-comm...@bugs6.perl.org> wrote:
> 
>  On Sat Jul 09 13:51:07 2016, tbrowder wrote:
>  > Need a pod2man translator.
>  Does this need to be shipped with the rakudo compiler?
> 
>Since the perl6 program --help once mentioned the perl6 man page, maybe
>it should.
> 
>-Tom
> 
> References
> 
>1. javascript:_e({},'cvml','bugs-comm...@bugs6.perl.org');

Re: [perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents

[Patrick R. Michaud via RT]

On Sat, Jul 09, 2016 at 05:19:49AM -0700, Itsuki Toyota wrote:
> See the following results
> 
> $ perl6 -e 'say -1 ** -0.1'
> -1
> $ perl6 -e 'say reduce * ** *, -1, (-0.1)'
> NaN

This is not a bug in "reduce" itself.  Exponentiation has higher 
precedence than unary minus, so the first expression is being
parsed and executed as -(1 ** -0.1)  and not  (-1) ** -0.1.
>From my rakudo (ver 2016.06-50-g5a4963f):

$ ./perl6 -e 'say -1 ** -0.1'
-1
$ ./perl6 -e 'say (-1) ** -0.1'
NaN

So, the reduce subroutine is doing exactly the same thing as :<**> here 
does with a negative base.

At the moment I'm inclined to believe that a negative integer with
negative exponent should return NaN, but someone with more mathematics
sense than I would have to make that call.

Pm

Re: [perl #128584] [BUG] reduce subroutine returns NaN when calculating decimals with negative exponents

[Patrick R. Michaud]

On Sat, Jul 09, 2016 at 05:19:49AM -0700, Itsuki Toyota wrote:
> See the following results
> 
> $ perl6 -e 'say -1 ** -0.1'
> -1
> $ perl6 -e 'say reduce * ** *, -1, (-0.1)'
> NaN

This is not a bug in "reduce" itself.  Exponentiation has higher 
precedence than unary minus, so the first expression is being
parsed and executed as -(1 ** -0.1)  and not  (-1) ** -0.1.
>From my rakudo (ver 2016.06-50-g5a4963f):

$ ./perl6 -e 'say -1 ** -0.1'
-1
$ ./perl6 -e 'say (-1) ** -0.1'
NaN

So, the reduce subroutine is doing exactly the same thing as :<**> here 
does with a negative base.

At the moment I'm inclined to believe that a negative integer with
negative exponent should return NaN, but someone with more mathematics
sense than I would have to make that call.

Pm

Re: [perl #125427] [BUG][Feature][GLR] Can't define custom flat prefix op with pipe

[Patrick R. Michaud]

On Wed, Jun 17, 2015 at 12:24:04AM -0500, Patrick R. Michaud wrote:
 In Rakudo unary | is a syntactic construct that can't be overloaded.
 
 So, notabug.  :)

More directly to the comment about unary | possibly working outside of 
argument lists, I'm not sure we want to enable the case where unary-| 
means something very different outside of an argument list than in it.  
I suspect it could be made to do so, however, in which case  (| ... ) 
would be a valid flattening syntax.  But I see significant confusion
potential here, which is perhaps best avoided.

Pm

Re: [perl #125427] [BUG][Feature][GLR] Can't define custom flat prefix op with pipe

[Patrick R. Michaud]

On Tue, Jun 16, 2015 at 09:28:28PM -0700, Brent Laabs wrote:
 07:02 labster m: multi sub prefix:| (\a) { a.flat }; say
 (|[1,2,3]).perl
 07:02 camelia rakudo-moar d6430c: OUTPUT«5===SORRY!5=== Error while
 compiling /tmp/jvrQI4RBsS␤Arg-flattening | is only valid in an argument
 list␤at /tmp/jvrQI4RBsS:1␤-- 3i sub prefix:| (\a) { a.flat }; say
 (|7⏏5[1,2,3]).perl␤»
 
 Expected, one of:
  A) single pipe works as shorthand for flat outside of arg list
  B) Rakudo allows me to define my own flat operator (though, in this case,
 prefix:||| does work)
 
 Maybe this should be notabug, but if so I'd like an explanation as to why
 neither A nor B should work.

Unary | already has a defined syntactic meaning in Perl 6 (argument 
list interpolation -- see S06 / Flattening argument lists).  

In Rakudo unary | is a syntactic construct that can't be overloaded.

So, notabug.  :)

Pm

Re: New Logo Design for perl6 modules

[Patrick R. Michaud]

Let's not forget the raptors.  (Both Veloci and Utah are candidates. :)

Pm

On Thu, Jun 11, 2015 at 07:45:06PM -0700, Darren Duncan wrote:
 Or a pumpkin for that matter, since Perl 5 is Pumpkin Perl. -- Darren Duncan
 
 On 2015-06-11 7:42 PM, Darren Duncan wrote:
 I was going to say that too, about the camel trademark issues, so can you 
 make a
 version using an onion instead of a camel?  See http://www.perlfoundation.org
 for what I refer to. -- Darren Duncan
 
 On 2015-06-10 11:34 PM, Moritz Lenz wrote:
 Hi,
 
 On 06/10/2015 02:01 PM, Lin Yo-an wrote:
 Hi folks!
 
 I designed a logo for CPAN, and I think it can be used for perl6
 modules, don't know if you're interested in it?
 https://twitter.com/c9s/status/608549774648692736
 
 Great, I like it!
 
 Is there a high-res version available? What's the license?
 
 Any chance we can get a p5/p6 twin theme (like, one with a butterfly, in
 addition to the one with the camel)?
 It would be awesome to have cpan.org or metacpan.org and modules.perl6.org 
 with
 clearly related but distinct art work.
 
 One word of caution: the use of the camel in relation to Perl is a 
 trademark by
 O'Reilly.
 
 Cheers,
 Moritz
 
 
 
 

Re: [perl #125391] Wrong order with %% $delim=.*

[Patrick R. Michaud]

On Thu, Jun 11, 2015 at 02:53:15PM -0700, Alex Jakimenko wrote:
 say grammar Gram { regex TOP { ('XX')+ %% $delim=[a..z]* };
 }.parse('XX');
 
 Output:
 ｢XX｣
  0 = ｢XX｣
  0 = ｢XX｣
  delim = ｢｣
  0 = ｢XX｣
  delim = ｢｣
  delim = ｢｣
 
 The order is wrong. 

I'm not entirely certain this is a bug, although it might be less than optimal. 
 By using 'say' we're seeing the .gist of the resulting Match object, which in 
turn is using .caps .  The .caps method sorts the captured parts based on the 
.from of each submatch.

In this case, $delim[0] and $0[1] both have a .from of 2.  Since their 
.from's result in a tie, the one that happens to be earlier in the capture hash 
('0' in this case) ends up appearing first (since sorting is stable).

I guess we can update .caps to sort based on both the .from and .to values of 
each submatch, although doing so will likely make .caps a fair bit slower.

Pm

Re: [perl #125334] min(+'a', +'a').say prints Inf but should produce an error

[Patrick R. Michaud]

On Mon, Jun 08, 2015 at 06:08:33AM -0700, Will Coleda via RT wrote:
 I agree that this should be throwing the same conversion error. 

I disagree to the extent that making min() throw the conversion error seems
to go against the purpose of designing soft/lazy Failure types into Perl 6
in the first place.

Sometimes we speak about not having the entire rocket explode simply
because of a few errors in the input set.  In this case, min() is designed
to silently ignore undefined values in its calculations.  Since in this
example all of the input values were undefined, min returned its 0-arg
case of Inf.

Perhaps an argument could be made that if min() is invoked on a list
consisting only of undefined values, it should return the first (undefined)
value instead of Inf.  In other words, undefined values end up in this
middle-region between lowest defined value and Inf, or something like
that.

At any rate, at this moment it's more of a specification issue than an
actual rakudobug.

Pm

Re: [perl #123800] [BUG] copy doesn't copy the umask in Rakudo

[Patrick R. Michaud]

On Wed, Feb 11, 2015 at 04:21:32PM -0500, Parrot Raiser wrote:
 Not replicating the original file permissions on a copy would be a
 huge security hole. Anybody could copy a root-read-only file, examine
 the contents, modify them, and, if they had write access to the
 directory, replace it with the updated one.

I think this is overstating things a fair bit.  A file that is root-read-only 
would only be readable by root, not anybody.

Assuming a non-root person has read permissions to a file that is 
root-read-only (whatever that means), there are plenty of ways to create a 
modifiable copy of that file without using copy.  So copy itself isn't the 
source (or fix) of the security hole.

Ultimately I agree that the original file permissions should come into play, 
however.  I suspect that copy should create the new copy with the existing 
file's permissions as modified by the current umask.

Pm

Re: [perl #122892] [BUG] Scoping issue with regex using attribute in method in Rakudo

[Patrick R. Michaud]

On Fri, Oct 03, 2014 at 06:48:50AM -0700, Carl Mäsak wrote:
 masak m: class C { has $.sep = |; method foo { .say for
 foo|bar.split(/$!sep/).map(~*) } }; C.new.foo
 camelia rakudo-moar da3aae: OUTPUT«foo|bar␤»
 masak TuxCM: interesting.
 * masak submits rakudobug

14:09 pmichaud m: class C { has $.rx = 'bc';  method foo { say 'abcd' ~~ 
/$!rx/; } };  C.new.foo
14:09 camelia rakudo-moar da3aae: OUTPUT«Nil␤»
14:10 pmichaud I'm guessing that regexes don't know how to interpolate $!vars
14:10 pmichaud m: class C { has $.rx = 'bc';  method foo { say $!rx; say 
'abcd' ~~ /$!rx/; } };  C.new.foo
14:10 camelia rakudo-moar da3aae: OUTPUT«bc␤Nil␤»
14:11 moritz or maybe the attribute lookup gets the cursor object as invocant?

Pm

[perl #122882] [BUG] Symmetric set difference (^) doesn't right-associate or chain in Rakudo

[Patrick R. Michaud via RT]

Added tests in roast/S03-operators/set.t, marking ticket resolved.

Pm

Re: [perl #122882] [BUG] Symmetric set difference (^) doesn't right-associate or chain in Rakudo

[Patrick R. Michaud]

On Wed, Oct 01, 2014 at 09:00:08PM -0700, Carl Mäsak wrote:
 masak m: say jet plane (^) network lag (^) plane network
 
 It's an interesting question in itself where the error message Too
 many positionals passed; expected 2 arguments but got 3 comes from.
 Does the (^) operator somehow declare itself as chaining, but then has
 no capability to handle a longer chain of operands? Just guessing
 here.

I noticed this a few weeks ago when playing with the set operators.  The 
problem is that infix:(^) is correctly declared as having list associativity 
(it's at junctive_or precedence), but is defined as a binary operator in 
src/core/set_operators.pm.  This is the reason for the expected 2 arguments 
but got 3 message.

For comparison, note that infix:(|) is defined in src/core/set_operators.pm as

sub infix:(|)(**@p)

infix:(^) needs to have a similar declaration instead of the 2-argument form 
that is there now.

Pm

Re: [perl #120638] Empty array reference in a loop leaks memory on rakudo-parrot

[Patrick R. Michaud]

I have a strong suspicion that this bug is related to
https://github.com/parrot/parrot/issues/795 .  As demonstrated
in that issue, Parrot tends to gobble up all available memory 
even in a simple case of allocating and releasing an array, 
and once the process is at the edge of its memory allocation 
limits various panics can easily ensure.

It might very well be something else, but I just wanted to 
point out the known issue with Parrot's GC in this context.

Pm

Re: [perl #120480] recursion_limit bad assumption

[Patrick R. Michaud]

On Thu, Nov 14, 2013 at 06:13:39AM -0800, Will Coleda via RT wrote:
 This is only used for parrot - it's a noop on the other 2 nqp backends.
 I recommend wrapping this line in a #? preprocessor block for parrot 
 only, and changing the comment to reflect that we're just doing this 
 for a single vm.

In general I greatly prefer to reduce the number of #? preprocessing 
blocks, not increase them.  In this case I'd prefer to simply change 
the comment to reflect what's really happening and then close this 
ticket.

Even though we don't have a recursion limit for other backends, I
can greatly imagine there would be some utility to adding one at
some point in the future.

Pm

[perl #119875] [BUG] term:^^ doesn't consider a last empty line as a line in regexes in Rakudo

[Patrick R. Michaud via RT]

S05:792 mentions this case explicitly:

^^ always matches the beginning of the string and after
any \n that is not the final character in the string.

So, rakudo is performing exactly as specced.

I suspect the reason behind the spec is so that slurped \n-terminated 
files (i.e., the vast majority) aren't treated as having an extra blank 
line after the final \n.

Rejecting ticket,

Pm

Re: [perl #98954] [BUG] Nested indexing semantics changed from Beijing to nom in Rakudo

[Patrick R. Michaud]

On Thu, Sep 12, 2013 at 11:48:02AM -0700, Carl Mäsak via RT wrote:
 These days, it fails.
 
 masak rn: my @a = [1], [2], [3]; say (map { @a[1 - $_][0] }, 0 .. 
 3).perl
 camelia niecza v24-95-ga6d4c5f: OUTPUT«(2, 1, Any, Any).list␤»
 camelia ..rakudo 69c3cc: OUTPUT«(2, 1, Failure.new(exception = 
 X::AdHoc.new(payload = Cannot use negative index -1 on Array)), 
 Failure.new(exception = X::AdHoc.new(payload = Cannot use negative 
 index -2 on Array))).list␤»
 * masak amends RT #98954
 
 Which is arguably more correct than silently truncating the result list. 
 (But still different from both Beijing and Niecza.)

S09:683 says that Negative subscripts are never allowed for standard
subscripts unless the subscript is declared modular.

I know S09 is slushy, but afair once the whatever star notation was
introduced it's always been the intent that negative indices would
fail unless explicitly declared to be valid somehow.

Pm

[perl #118541] $ context specifier

[Patrick R. Michaud via RT]

The wikibooks example is wrong, Rakudo is correct here.  


(To return the number of elements, use prefix:+, not the $-
contextualizer.)

Actually, that whole section in wikibooks seems to be a little off... 
@() doesn't mean convert to array, for example.

Closing ticket.

Pm

Re: [perl #118519] ▁ ▂ ▃ ▄ ▅ ▆ ▇ █␤, alas no

[Patrick R. Michaud]

 23:45:53] TimToady   nr: say '▁' ... '█'
 [23:46:07] +camelia  rakudo b2072f: OUTPUT«(timeout)»

Now fixed in af50a6e:

 say '▁' ... '█'
▁ ▂ ▃ ▄ ▅ ▆ ▇ █

Closable with tests.

Pm

[perl #118479] Untyped hashes are considered to be {Str}, but act differently from hashes typed with {Str}

[Patrick R. Michaud via RT]

 So either STORE_AT_KEY for typed hashes should stringify objects
silently if the keytype is Str, like untyped hashes do.  Or untyped
hashes should *not* automatically stringify objects.

Untyped hashes are {Str(Any)} -- see S09:1187:

The standard Hash:
my %hash;
is really short for:
my Mu %hash{Str(Any)};

This accounts for the difference between the two; an untyped hash will 
accept Any key and coerce it to a Str, while a hash declared {Str} will 
only accept Str values as keys.

Closing ticket,

Pm

Re: Fwd: [Passed] letolabs/parrot-libgit2#21 (nciupdate - 4d61364)

[Patrick R. Michaud]

The parrot-nqp.c file is generated by the pbc_to_exe program, which 
contains the source lines referenced here.  The source for pbc_to_exe 
is in tools/dev/ .

HTH,

Pm

On Sat, Jun 01, 2013 at 12:46:46PM -0500, Jonathan Duke Leto wrote:
 Howdy,
 
 I think my GSoC student has possibly found a bug in parrot-nqp. I
 won't have much time during YAPC::NA to help him.
 
 Could anybody step in and help him debug this issue?
 
 Duke
 
 
 -- Forwarded message --
 From: Saurabh Kumar saurabhgee...@gmail.com
 Date: Sat, Jun 1, 2013 at 11:55 AM
 Subject: Re: [Passed] letolabs/parrot-libgit2#21 (nciupdate - 4d61364)
 To: Jonathan Duke Leto jonat...@leto.net
 
 
 On Sat, Jun 1, 2013 at 8:12 PM, Jonathan Duke Leto jonat...@leto.net 
 wrote:
  Howdy,
 
  Can you show me where (a link to Github is most useful) where you
  think the NQP exit code bug is?
 
  Thanks!
 
 Ah, sorry, I was looking at parrot-nqp.c, which seems to be a
 generated file, and not in the parrot.git repository. The main
 function in the C file (Around line 37296) seems to have 7 locations
 where it can exit. Before the program exits successfully, this is the
 only location that should give off an error:
 
  if (!Parrot_api_run_bytecode(interp, pbc, argsarray)) {
 show_last_error_and_exit(interp);
 }
 
 Apparently this doesn't show a error. I'm not sure which source file
 generates this C file now. I will look into it.
 
 
 -- 
 Jonathan Duke Leto jonat...@leto.net
 Leto Labs LLC http://letolabs.com
 209.691.DUKE http://duke.leto.net
 @dukeleto

Re: [perl #114760] [BUG] Minus thirteen billion years ago becomes minus 115 million years ago in DateTime.new in Rakudo

[Patrick R. Michaud]

On Thu, May 30, 2013 at 03:12:02AM -0700, Carl Mäsak via RT wrote:
 masak (), coke ():
   masak r: say Date.new(-13_000_000_000, 1, 1)
   p6eval rakudo cc1858: OUTPUT«-115098112-01-01␤»
   masak o.O
   masak I suppose -115098112 above is a bug?
  
  This seems consistent with trying to use a value that is too big for
  an Int (which $.year is); are
  you arguing that this should throw an error, that an Int $.year should
  autopromote to something
  else, or that $.year should be declared as something else?

How is it possible for a value to be too big for an Int?  Could this
be rephrased or re-analyzed somehow?

Pm

Re: [perl #114760] [BUG] Minus thirteen billion years ago becomes minus 115 million years ago in DateTime.new in Rakudo

[Patrick R. Michaud]

On Thu, May 30, 2013 at 11:54:30AM -0400, Will Coleda wrote:
 I was trying to imply that it was an overflow error.

Okay.  I suspect the overflow is not because of the Int, but because
of the use of sprintf() in the date/time formatting routines, which
doesn't handle large integers properly.  See also RT #118253.

Switching the formatter to (temporarily?) use %s instead of %d might 
resolve the problem, as stringification of large ints works fine.

Pm

Rakudo Star 2013.05 released

[Patrick R. Michaud]

## A useful, usable, early adopter distribution of Perl 6

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the May 2013 release of Rakudo Star, a useful and usable
distribution of Perl 6. The tarball and Windows .MSI for the May 2013 
release are available from http://rakudo.org/downloads/star/. 

In the Perl 6 world, we make a distinction between the language
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes [release 2013.05] of the
[Rakudo Perl 6 compiler], version 5.2.0 of the [Parrot Virtual
Machine], plus various modules, documentation, and other resources
collected from the Perl 6 community.

[release 2013.05]:
https://github.com/rakudo/rakudo/blob/nom/docs/announce/2013.05.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[Parrot Virtual Machine]: http://parrot.org

Some of the new features added to this release include:

* The ?-quantifier on regex captures now returns a single Match object 
  (formerly returned an array).  Use `** 0..1` to get the old behavior.
* Failed matches return Nil instead of a false Match object.
* Rakudo warns when pure expressions are used in sink context
* .substr(...) now correctly accepts whatever-star closures
* Implemented shellwords postcircumfix (%h $x 'foo bar' )
* Defining operators spelled like the empty string is now illegal
* Array interpolations now properly do LTM
* Autothread none and all junctions before any and one
* Helpful error if you write else if/elif instead of elsif
* Throw exception if a Range is used as a Range endpoint
* Corrected argument order in IO.seek
* wrap low level VM objects in ForeignCode, allowing perl6 OO calls on them
* for loops are eager again
* add link and symlink to IO
* add Capture.Bool()
* improvements to DUMP()
* various optimizations in the optimizer and the runtime
* smartmatch against list now supports Whatever wildcards
* IO::Spec, a port of Perl 5's File::Spec
* regex special characters can be used as delimiters
* allow slice with :exists adverb on hashes
* added 125 extra opening/closing bracket-pairs

This release also contains a range of bug fixes, improvements to error
reporting and better failure modes.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are planned
to be removed or changed as follows:

  * `postcircumfix:[ ]` and `postcircumfix:{ }` will become
multi-subs rather than multi-methods. Both at_pos and at_key will
remain methods.

  * Unary hyper ops currently descend into nested arrays and hashes.
This will change to make them equivalent to a one-level map.

  * The Str.ucfirst builtin is deprecated; it will be replaced by
Str.tc.

  * Leading whitespace in rules and under :sigspace will no longer be
converted to `.ws`.  For existing regexes that expect this
conversion, add a `?` in front of leading whitespace to make it
meta again.

  * The result of failed matches will be Nil instead of a Match
object returning boolean False.

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features
that lists the known implemented and missing features of Rakudo and
other Perl 6 implementations.

In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are many
that we've missed.  Bug reports about missing and broken features are
welcomed at rakudo...@perl.org.

See http://perl6.org/ for links to much more information about
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources.  A
draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in
the release tarball.

The development team thanks all of the contributors and sponsors for
making Rakudo Star possible.  If you would like to contribute, see
http://rakudo.org/how-to-help, ask on the perl6-compiler@perl.org
mailing list, or join us on IRC \#perl6 on freenode.

Re: Rakudo Star 2013.05 released

[Patrick R. Michaud]

On Thu, May 30, 2013 at 11:08:13PM -0500, Patrick R. Michaud wrote:
 This Star release includes [release 2013.05] of the
 [Rakudo Perl 6 compiler], version 5.2.0 of the [Parrot Virtual
 Machine] ...

Oops.  The 2013.05 release actually contains Parrot 5.3.0.

Sorry about the typo.

Pm

Re: [perl #117985] [BUG] :p adverb on hash lookup doesn't weed out a nonexistent hash key if it's the only key in Rakudo

[Patrick R. Michaud]

On Mon, May 13, 2013 at 11:54:38AM -0700, Carl Mäsak wrote:
 lizmat r: my %a= (a = 1, b = 2); say %ac:p  # shouldn't this be Nil ?
 camelia rakudo 2a04f2: OUTPUT«c = Any␤»
 masak lizmat: yeah, think so.
 * masak submits rakudobug

I'm pretty sure rakudo is correct in this case.
We know that %ac should return a value with a vivifying
WHENCE property (for assignment), so the only question is 
what value it should return.

In particular, my %h; is like saying my Any %h, in that the hash
is a set of Scalar containers that default to Any.  If the declaration
were my Int %h, then I'd expect %hc to return Int.


 masak r: my %a= (a = 1, b = 2); say %aa b c:p
 camelia rakudo 2a04f2: OUTPUT«a = 1 b = 2 ␤»

This is a legitimate bug, IMO.
I think there should be a c = Any pair returned here,
where the Any has a WHENCE clause to autovivify the hash
entry.  Again, consider %aa b c = 4..6;

Pm

Re: [perl #77624] [BUG] Base conversion of Str containing base conversion doesn't work in Rakudo

[Patrick R. Michaud]

On Fri, May 10, 2013 at 10:51:14PM -0700, Will Coleda via RT wrote:
 On Wed Sep 01 10:17:15 2010, masak wrote:
  TimToady rakudo: say :10(':16bad.decaf')
  p6eval rakudo dc9900: OUTPUT�DON'T PANIC! Invalid character (:)!
  Please try again :)
  pmichaud ...DON'T PANIC?
  masak that's lue's addition, I think.
  masak should the above work?
  pmichaud yes, the str-to-num conversions still need a fair bit of work.
  * masak submits rakudobug
 
 I'm not sure the original request makes sense. Can you point us at the spec 
 that says that this 
 should work? (Everything I see about :NN in S02 makes it look like a literal 
 syntax only.

S02:3326, Conversion functions, talks about :NN as a conversion
function.  In particular, all of the below should work:

 say :10('99')# correct
99
 say :16('99')# correct
153
 say :10('0x99')  # correct
153
 say :10(':1699')   # fail, should be 153
Cannot convert string to number: base-10 number must begin with valid 
digits or '.' in ':10⏏:1699' (indicated by ⏏)
  in method sink at src/gen/CORE.setting:10030
  in method BUILDALL at src/gen/CORE.setting:801
  in method bless at src/gen/CORE.setting:743
  in method new at src/gen/CORE.setting:728
  in method new at src/gen/CORE.setting:726

Pm

[perl #117923] [BUG] can not augment List class

[Patrick R. Michaud via RT]

On Wed May 08 18:16:40 2013, grond...@yahoo.fr wrote:
 This is perl6 version 2013.04-55-gfe70494 built on parrot 5.2.0
 revision RELEASE_5_2_0
 
 
 use MONKEY_TYPING;
 augment class List { proto method combinations(|) {*} }
 
 
 Cannot look up attributes in a type object

It works for me if I put a statement after the augment:

pmichaud@kiwi:~/p6/rakudo$ cat x.p6
use MONKEY_TYPING;
augment class List {
proto method combinations(|) { * }
}

say 1;
pmichaud@kiwi:~/p6/rakudo$ ./perl6 x.p6
1

I suspect the problem is that as the last statement in the block,
the augmented class is being returned to MAIN or some other 
top-level routine which is then trying to do something with
it (such as convert it to an integer exit code).

I can get the same error as the original ticket without using augment:

pmichaud@kiwi:~/p6/rakudo$ cat y.p6
use v6;

List;

pmichaud@kiwi:~/p6/rakudo$ ./perl6 y.p6
Cannot look up attributes in a type object
current instr.: 'gimme' pc 285293 (src/gen/CORE.setting.pir:125268) 
(src/gen/CORE.setting:6051)
called from Sub 'sink' pc 294400 (src/gen/CORE.setting.pir:128911) 
(src/gen/CORE.setting:6359)
called from Sub 'MAIN' pc 381 (src/gen/perl6.pir:147) (src/main.nqp 
src/gen/main-version.nqp:42)
called from Sub '' pc 77 (src/gen/perl6.pir:56) (src/main.nqp 
src/gen/main-version.nqp:1)
called from Sub '' pc 1127 (src/gen/perl6.pir:404) (src/main.nqp 
src/gen/main-version.nqp:52)
pmichaud@kiwi:~/p6/rakudo$ 

[perl #117923] [BUG] can not augment List class

[Patrick R. Michaud via RT]

Now fixed in b1695cf:

pmichaud@kiwi:~/p6/rakudo$ cat x.p6
use MONKEY_TYPING;
augment class List {
proto method combinations(|) { * }
}

pmichaud@kiwi:~/p6/rakudo$ ./perl6 x.p6
pmichaud@kiwi:~/p6/rakudo$ 

Ticket closable with tests (hint: test that List.sink doesn't fail).

Pm

Re: No more Rakudo *?

[Patrick R. Michaud]

On Tue, May 07, 2013 at 09:01:34AM +0300, Gabor Szabo wrote:
 Do I first need to manually clone Rakudo and the modules from Gihub
 and then use the --force or is
 there something else I need to do?
 Do I understand correctly that in a real Rakudo * release you'd check out the
 labeled release of Rakudo and the latest versions of the modules and
 then start the build process?

The rakudo/star repository contains the tools needed to build a
Rakudo Star tarball.  The repo itself doesn't contain the compiler
and/or module sources directly.

You don't (and shouldn't) manually clone the Rakudo and module repos
from GitHub, there's a Makefile in the repo that does that for you.  
See the tools/star/release_guide.pod file for the steps needed to build
and test a Rakudo Star distribution.  I've already done most of the steps 
needed to build the 2013.04 distribution, my latest candidate is
downloadable from:

   http://pmichaud.com/sandbox/rakudo-star-2013.04-rc2.tar.gz

The make modules-test part is failing for me in this candidate,
the failures I'm seeing are:

Testing modules/perl6-File-Tools...
t/01-file-find.t .. ok   
t/02-shell-command.t .. 1/12 Failed to remove the file 
't/dir2/foodir/not_a_dir': unlink failed: No such file or directory
  in block  at src/gen/CORE.setting:8121
  in sub unlink at src/gen/CORE.setting:8117
  in block  at 
/home/pmichaud/p6/star/work/rakudo-star-2013.04/install/lib/parrot/5.2.0/languages/perl6/lib/Shell/Command.pm:34
  in method reify at src/gen/CORE.setting:5737
  in method reify at src/gen/CORE.setting:5632
  in method gimme at src/gen/CORE.setting:6053
  in method eager at src/gen/CORE.setting:6032
  in sub rm_rf at 
/home/pmichaud/p6/star/work/rakudo-star-2013.04/install/lib/parrot/5.2.0/languages/perl6/lib/Shell/Command.pm:26
  in block  at t/02-shell-command.t:28

t/02-shell-command.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 7/12 subtests 

Test Summary Report
---
t/02-shell-command.t (Wstat: 256 Tests: 10 Failed: 5)
  Failed tests:  5-9
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 12 tests but ran 10.
Files=2, Tests=18,  2 wallclock secs ( 0.03 usr  0.01 sys +  2.01 cusr  
0.37 csys =  2.42 CPU)
Result: FAIL
   
and

Testing modules/perl6-lwp-simple...
t/000-load-module.t . ok   
t/basic-auth.t .. ok   
t/custom-headers-and-content.t .. Cannot call 'match'; none of these 
signatures match:
:(Cool:D : $target, *%adverbs)
  in method match at src/gen/CORE.setting:2477
  in block  at t/custom-headers-and-content.t:12

t/custom-headers-and-content.t .. Dubious, test returned 1 (wstat 256, 
0x100)
No subtests run 
t/get-binary-camelia.t .. ok   
t/get-chunked-6guts.t ... ok   
t/get-perl6-org.t ... ok   
t/get-unsized.t . Cannot call 'match'; none of these 
signatures match:
:(Cool:D : $target, *%adverbs)
  in method match at src/gen/CORE.setting:2477
  in block  at t/get-unsized.t:10

t/get-unsized.t . Dubious, test returned 1 (wstat 256, 
0x100)
No subtests run 
t/get-w3-latin1-utf8.t .. ok   
t/get-w3-redirect.t . ok   
t/getstore.t  ok   
t/parse-url.t ... ok
t/socket-sanity.t ... ok   
t/stringify-headers.t ... ok   

Test Summary Report
---
t/custom-headers-and-content.t (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
t/get-unsized.t   (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=13, Tests=54, 94 wallclock secs ( 0.11 usr  0.02 sys + 86.86 cusr  
2.66 csys = 89.65 CPU)
Result: FAIL

I suspect these failures aren't all that hard to find/fix; 
I just haven't had time to do it.

Pm

[perl #117875] Smartmatching ints against Enumeration Types fails (probably NYI)

[Patrick R. Michaud via RT]

Resolved via a change to S12, see 
https://github.com/perl6/specs/commit/bff62668057bf3f87a6f80f33d088d47a1d
4eda2 .

Pm

[perl #117831] [BUG] Grammar capture of '%' separator

[Patrick R. Michaud via RT]

Now fixed in 4741028:

pmichaud@kiwi:~/p6/rakudo$ cat g.pl
grammar G {
token TOP {letter +% sep}
token letter{[a..z]}
token sep{\,}
}

say G.parse(a,b,c,d).caps.map({$_.value});

pmichaud@kiwi:~/p6/rakudo$ ./perl6 g.pl
a , b , c , d
pmichaud@kiwi:~/p6/rakudo$ 

Needs tests to resolve the ticket.

Re: [perl #117841] [BUG] qx[] dies when multibyte UTF-8 characters split across 2048-byte chunk boundary in Rakudo

[Patrick R. Michaud]

On Thu, May 02, 2013 at 02:48:46PM -0700, Carl Mäsak wrote:
 FROGGS masak: shortest example evar!!: perl6 -e 'qx[perl6 -e say 1
 x 2047,q|—| | cat]'
 masak FROGGS++
 * masak submits rakudobug

I'm not able to reproduce this bug on my system.  Can we get more 
details, such as Rakudo version, Parrot version, and ICU version?

Thanks,

Pm

Re: [perl #117481] [BUG] duplicate keys in .gist in Match of regex which backtracked in Rakudo

[Patrick R. Michaud]

On Thu, Apr 04, 2013 at 02:09:36PM -0700, Carl Mäsak wrote:
 p6eval rakudo 99e27f: OUTPUT«｢/foo/bar/baz/｣␤ dirname =
 ｢/foo/bar/baz/｣␤ dirname = ｢/foo/bar/｣␤ basename = ｢baz｣␤␤»
 labster okay, why do I get two copies of dirname when the match only
 succeeds once?
 masak huuhhnn.
 masak wut.
 masak I suspect a backtracking-related glitch.
 ...
 The .gist output is bizarre. There should never be duplicate keys in a
 Match. 

The gist method uses .caps for the match output, so I suspect
the culprit is in caps, or in Match.gist's incorrect usage of .caps .   

Duplicate keys can appear in the .caps stream.

Pm

Re: [perl #117307] [BUG] Sequances with strings go backwards in Rakudo

[Patrick R. Michaud]

On Fri, Mar 22, 2013 at 03:31:57PM -0700, Carl Mäsak wrote:
 
 masak rn: say .[*-1] given perl ... { 3 == ++state $ }
 p6eval rakudo 221a95: OUTPUT«perj␤»
 p6eval ..niecza v24-35-g5c06e28: OUTPUT«pern␤»
 * masak submits rakudobug
 
 I'm just assuming this isn't spec'd behavior. I like Niecza's
 semantics better: use .succ if nothing else is indicated.

S03 has:

For functions deduced when there is only one value on the left, 
the final value is used to determine whether *.succ or *.pred is 
more appropriate.  The two values are compared with Ccmp to 
determine the direction of the progression.

Rakudo evaluates C perl cmp { ... }as COrder::Decrease,
therefore it's using the .pred/decreasing progression.

So, one of the following:
  a) infix:cmp should produce a different result for Str vs Code
 (if so, what?),
  b) infix:... should assume .succ if the final value is a Code object,
  c) Rakudo is correct, or
  d) Some other spec clarification or change needs to be made.

Pm

Re: [perl #117307] [BUG] Sequences with strings and a Code stopping condition go backwards in Rakudo

[Patrick R. Michaud]

On Sat, Mar 23, 2013 at 07:50:55AM -0700, Carl Mäsak via RT wrote:
b) infix:... should assume .succ if the final value is a Code 
 object,
 
 This alternative makes sense to me. It's similar to how infix:... 
 assumes .succ in this case: 'perl ... *'

Similar, yes, but also a little off.  In the case of perl ... * ,
infix:... assumes .succ because the * transforms to Inf, and
perl cmp Inf is Order::Increase.  So, it's a special case like *, 
but it's a separate special case.

I'm wondering if Code objects just shouldn't participate in 
infix:cmp somehow.  

And also if there ought to be something akin to an Order::None 
somewhere.

Either of these might help to more cleanly get the infix:... 
semantics right in this case, as well as potentially solve a 
lot of other cmp-related oddities.

Pm

Re: [perl #117235] [BUG] Deep-cloned array loses its original content on .unshift in Rakudo

[Patrick R. Michaud]

On Thu, Mar 21, 2013 at 08:49:42AM +0100, Moritz Lenz wrote:
 -method sink() {
 -self.gimme(*, :sink);
 +method sink(\SELF:) {
 +SELF.gimme(*, :sink) unless nqp::iscont(SELF);
  Nil;
  }
  }
 
 
 But of course it's not a real fix. Should I apply it?

I think I prefer

method sink(\SELF:) {
SELF.gimme(*) unless nqp::iscont(SELF);
Nil;
}

because I'm not entirely certain that :sink is safe in
all cases (and it may go away anyway).

Pm

Re: [perl #117237] error building rakudo star 2013.02

[Patrick R. Michaud]

On Wed, Mar 20, 2013 at 04:41:16PM -0700, James Buster wrote:
 I believe this error is occurring because something is looking for 
 nqp_dyncall_ops.so in a place other than would
 be implied by the -prefix argument to Configure.pl. That is, it's probably 
 looking in /usr/lib or /usr/local/lib and not finding it.
 That's what you'd expect because it shouldn't looking in those places, it 
 should be looking in $prefix/lib/parrot/version/dynext,
 which is where the Configure process actually installed it. Unfortunately I'm 
 not familiar enough with the perl6 build process to know
 where the lookup failure is occurring.
 [...]
 Stage start  :   0.000
 error:imcc:loadlib directive could not find library `nqp_dyncall_ops'

Parrot's loadlib directive normally looks in 
$prefix/lib/parrot/version/dynext,
so I'm not exactly sure what the problem is here.  I doubt it's looking only
in /usr/lib and /usr/local/lib, as you suggest.  Something else must be at
play here.

OOC, what version of Parrot is listed in the /build/jamesb/local/lib/parrot ?

Also, is there any chance that there's another Parrot installed somewhere on
the system?  Perhaps the perl6 binary is finding/loading that one by mistake.

Pm

Re: naming the test of arrays defined

[Patrick R. Michaud]

On Thu, Mar 21, 2013 at 04:52:16PM +, Nicholas Clark wrote:
 On Thu, Mar 21, 2013 at 04:50:40PM +, Nicholas Clark wrote:
 
 Bother. That should have been more to perl6-language than perl6-compiler.
 Should I resend it?

Either is fine for this; since we're really into a bit of
an implementation detail I'd leave the discussion on p6c.

Pm

Re: naming the test of arrays defined

[Patrick R. Michaud]

I don't quite follow the unease from this example, but that's
probably because of the way that Perl 6 thinks of undefined
being different from Perl 5's undef and defined. 

In particular:

 ...
 sub array {
 my $what = shift;
 my $array = [];
 return $array if $what eq 'undef';

Perl 6 wouldn't treat C my $array = [];   as having
any sort of undefined result -- it's absolutely
a defined Array (albeit empty).  In Perl 6, the way
one would obtain an undefined array is with something
like

my $array = Array;

or

my @array;# rakudo currently gets this wrong,
  # which is part of what brought up
  # the discussion on #perl6  :-)

Or, put another way, in Perl 6 an undefined array
is denoted by its type object (just like most other
undefined values such as Int, Str, etc.).

Hope I've not just confused things even further.

Pm

Re: [perl #117235] [BUG] Deep-cloned array loses its original content on .unshift in Rakudo

[Patrick R. Michaud]

On Thu, Mar 21, 2013 at 08:14:08PM +0100, Moritz Lenz wrote:
 On 03/21/2013 01:40 PM, Patrick R. Michaud wrote:
  On Thu, Mar 21, 2013 at 08:49:42AM +0100, Moritz Lenz wrote:
  -method sink() {
  -self.gimme(*, :sink);
  +method sink(\SELF:) {
  +SELF.gimme(*, :sink) unless nqp::iscont(SELF);
   Nil;
   }
   }

This doesn't seem to be sufficient; as $c.unshift(47) still
fails on my system.  The List coming back from .unshift is
currently decontainerized.

In the meantime, I've added a test for this ticket as
S04-statements/sink.t .  It's not included in Rakudo's spectests
yet.

Pm

Re: [perl #117235] [BUG] Deep-cloned array loses its original content on .unshift in Rakudo

[Patrick R. Michaud]

On Wed, Mar 20, 2013 at 12:41:41PM -0700, Carl Mäsak wrote:
 # New Ticket Created by  Carl Mäsak 
 # Please include the string:  [perl #117235]
 # in the subject line of all future correspondence about this issue. 
 # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117235 
 
 masak just found my heisenbug :)
 masak yeah, this is a weird one.
 diakopter run it?
 masak rn: my $c = [[1]].map({ [ @$_ ] }); $c.push( 42 ); say $c.perl
 p6eval rakudo 9be4cc, niecza v24-35-g5c06e28: OUTPUT«([1], 42).list.item␤»
 masak rn: my $c = [[1]].map({ [ @$_ ] }); $c.unshift( 42 ); say $c.perl
 p6eval rakudo 9be4cc: OUTPUT«(42,).list.item␤»
 p6eval ..niecza v24-35-g5c06e28: OUTPUT«(42, [1]).list.item␤»
 * masak submits rakudobug
 masak rn: my $c = [[1], [2], [3]].map({ [ @$_ ] }); $c.unshift( 42
 ); say $c.perl
 p6eval niecza v24-35-g5c06e28: OUTPUT«(42, [1], [2], [3]).list.item␤»
 p6eval ..rakudo 9be4cc: OUTPUT«(42,).list.item␤»
 
 Niecza is right throughout, of course. The .unshift method adds
 elements; it doesn't remove them.

The problem is apparently with sink context, not .unshift.  I have a temporary
fix in mind, but can't get to it until Wednesday night or Thursday night.

20:26 pmichaud I wonder if the problem is related to sink context.
20:26 pmichaud r: my $c = [[1],[2],[3]].map( { $_ } ); $c.unshift(42).say
20:26 p6eval rakudo 9be4cc: OUTPUT«42 1 2 3␤»
20:26 pmichaud $c.unshift(42); is being evaluated in sink context.
20:26 moritz that might be it
20:27 pmichaud r: my $c = [[1],[2],[3]].map( { $_ } ); $c.unshift(42).sink;  
say $c.perl;
20:27 p6eval rakudo 9be4cc: OUTPUT«(42,).list.item␤»
20:27 pmichaud there ya go.
20:27 moritz niecza doesn't implement sink context
20:27 masak huh.
20:28 pmichaud r: my $c = [[1],[2],[3]].map( { $_ } ); $c.sink;  say $c.perl;
20:28 p6eval rakudo 9be4cc: OUTPUT«().list.item␤»
20:29 moritz pmichaud: c4083c42f2e63c97254b7a215a858913c4ff4a44 is the 
relevant merge commit
20:29 pmichaud golfed.

Pm

Re: Rakudo * 2013.02

[Patrick R. Michaud]

I haven't made the 2013.02 .msi yet.  I'll do that today, though.  :-)

Pm

On Wed, Mar 13, 2013 at 12:13:47PM -0400, Will Coleda wrote:
 I assume you're referring to the .msi ?
 
 
 On Wed, Mar 13, 2013 at 12:08 PM, Gabor Szabo szab...@gmail.com wrote:
 
  1) I think it has not told me the installation finished - it was just done.
  2) It installed in c:\rakudo without a question or without telling me
  it will do so
  3) It has not configured PATH to include c:\rakudo
  After doing it manually, perl6 -v worked from the command line.
 
  4) You cannot use p6doc from the command line so I created a file called
  c:\rakudo\bin\p6doc.bat   with the following content:
  @%~dp0perl6.exe %~dp0p6doc %*
 
  this will launch the perl6.exe from the same directory where the
  p6doc.bat file is and will pass all the
  parameters it got to the script.  After that runningp6doc Str  worked
 
  5) Same with panda
  c:\rakudo\bin\panda.bat   with the following content:
  @%~dp0perl6.exe %~dp0panda %*
 
  Explanation:
  The leading @ turns off echoing the command
  %~dp0 is the path to the directory where the bat file currently
  executed can be found, it already includes the trailing back-slash \
  %* includes all the command line parameters
 
  6) After a bit of searching I found that the
  c:\rakudo\lib\parrot\4.10.0\languages\perl6\lib is the location where
  the modules coming with Rakudo * are installed
  but I have not found any easy way to list them. Is there any? Is there
  a list of the modules that come with Rakudo * ?
 
  That's it for now.
 
 
 Gabor
 
 
 
 
 -- 
 Will Coke Coleda

Re: [perl #116897] while (...splice...) runs forever

[Patrick R. Michaud]

On Thu, Feb 21, 2013 at 09:07:44AM -0800, Ricardo SIGNES wrote:
 This program never terminates:
 
   use v6;
 
   my @a =  ;
   while (my @c = splice @a, 0, 3) {
 say one more;
   }

After each splice, @c ends up being @(Any, Any, Any).  I'm not
sure if this is correct; I can see that it should probably
return whatever is actually in the array and not pad.

The following should work:

my @a = ();

while ( @a ) {
   my @c = splice @a, 0, 3;
   say one more;
}

Hope this helps,

Pm

Re: deleting delete and exist need not exist

[Patrick R. Michaud]

On Mon, Feb 11, 2013 at 09:56:31AM +, Nicholas Clark wrote:
 Here are a better set of patches for Rakudo. They don't duplicate the check
 for $p  0, and they avoid calling nqp::elems(), by assuming that nqp::atpos()
 safely return nql::null() for indices beyond the end of the array.
 (Which Parrot does. Is any of this spec'd anywhere?)

AFAIK, Parrot has never spec'd that elements beyond the end of array
return PMCNULL, which is one reason I've avoided relying on it.
Also, I'm concerned that other VM platforms might not have the same 
characteristic as Parrot, while I am sure that nqp::elems() will
be available and will be inexpensive.

 This still holds. Style-wise, it would be possible to avoid using return-rw
 by using a nested ?? !! - which is considered better?

Since return-rw involves extra function calls (to return-rw, for one,
plus the internal code blocks it uses) and various exception handlers 
to capture and handle the return, it's definitely worth avoiding 
when not needed.

Pm

Re: [perl #116280] [BUG] NaN, Inf, -Inf aren't padded with spaces in sprintf in Rakudo

[Patrick R. Michaud]

On Tue, Jan 08, 2013 at 11:52:12AM -0800, Carl Mäsak via RT wrote:
 On Tue Jan 08 11:40:37 2013, FROGGS.de wrote:
  This would mean to bring over 500 lines of C code to nqp/rakudo.
 
 Is that an absolute claim? What about wrappers?

Currently Rakudo uses Parrot's sprintf features.  I wouldn't
recommend wholesale copying of Parrot's sprintf code, fwiw; I
think it could be done better, and there's a lot of stuff
that Parrot does in this area that we don't want.

  And this would mean that it doesn't get faster. Is it worth it?
 
 In my mind, correctness trumps speed. 

Agreed.  There are rare times when fast but incorrect is 
okay, but I'm not sure this is one of them.

Beyond that, we ultimately will have to solve the formatted
print issue in the general case for Perl 6 implementations... 
and C code might not be the best answer.  

I wonder what it would take to write a version of sprintf in 
Perl 6 or NQP directly, ignoring all speed aspects for the time
being.  Then we'd at least have something portable, provably
correct, easily modified, and that could be used as a reference
implementation.  It also might give some pointers on what can
be done to ultimately deal with speed issues.

Pm

Re: [perl #116280] [BUG] NaN, Inf, -Inf aren't padded with spaces in sprintf in Rakudo

[Patrick R. Michaud]

On Tue, Jan 08, 2013 at 05:02:21PM -0500, Will Coleda wrote:
 Is now a good time to ask if we still want to use the sprintf 
 slang in perl 6?

Yes, see also https://github.com/perl6/specs/issues/13 .

Pm

Re: [perl #116196] min does not work properly on array of array

[Patrick R. Michaud]

On Mon, Dec 24, 2012 at 09:16:28PM -0800, Tin Y Pang wrote:
 in rakudo 2012.11, min is not functioning properly with Z
 
 ./perl6 -e 'my @a = ([0, -20, 0], [0, -19, -1], [-1,
 -18, 0], [0, -17, 1], [1, -16, 0], [0, -15, -1],
 [0, -14, 1], [1, -13, 0]); say [Zmin] @a'
 
 gives -1 -13 -1
 expect -1 -20 -1


Note that -13 min -20  is -13:

 say -13 min -20
-13
 say -13 min -20
-20

I'm not sure I'm understanding the example above, but at first glance
it looks to me as though Rakudo is correct here.

Pm

Rakudo Star 2012.08 released

[Patrick R. Michaud]

On behalf of the Rakudo and Perl 6 development teams, I'm happy to
announce the August 2012 release of Rakudo Star, a useful and
usable distribution of Perl 6.  The tarball for the August 2012
release is available from http://github.com/rakudo/star/downloads.
A Windows .MSI version of Rakudo Star is also being made available
in the downloads area.

In the Perl 6 world, we make a distinction between the language 
(Perl 6) and specific implementations of the language such as
Rakudo Perl.  This Star release includes release 2012.08 [0] of the
Rakudo Perl 6 compiler [1], version 4.6 of the Parrot Virtual
Machine [2], and various modules, documentation, and other
resources collected from the Perl 6 community.

Some of the new features added to this release include:

* Rakudo Star now includes a Perl 6 debugger!  The debugger allows
  single-stepping, setting breakpoints, variable inspection/modification, 
  regex debugging, and more!  Enter perl6-debug script.pl to run 
  a script in debugging mode.  Enter help from a debug prompt to
  see the available commands.

* Memory usage of the build stage has been reduced by 35% - 40%.  This
  makes it possible to build and compile Rakudo Star on machines with
  less memory (although 1.2GB may still be needed for some 64-bit
  environments).

* Variables prefixed by | or \ in signatures are now sigilless, per updates
  to the Perl 6 specification.

* Circularities in module loading are now detected.

* An improved inliner, allowing a wider range of routines to be inlined.

* Str.bytes and lcfirst have been removed.  The tclc builtin
  has been added.

* 'abs' is now a normal subroutine instead of a prefix operator.

* IO::File and IO::Dir have been removed.

* The integer argument to IO::Socket.recv is now interpreted as 
  a number of characters/codepoints.

This release also contains a range of bug fixes, improvements to error
reporting and better failure modes. More exceptions are thrown as typed
exceptions, and more meta-model errors have been fixed to properly
report line numbers.

The following features have been deprecated or modified from previous
releases due to changes in the Perl 6 specification, and are being removed
or changed as follows:

* Parameters preceded by a | or \ can no longer have a sigil.

* IO::Path.dir (which returns the directory part of the path) has been
  renamed to IO::Path.directory.  IO::Path.dir will be removed or
  re-purposed.

* The Str.ucfirst builtin is deprecated; it will be replaced by Str.tc.

* The (experimental) LAZY statement prefix will soon be removed.

* Leading whitespace in rules and under :sigspace will no longer be
  converted to .ws .  For existing regexes that expect this conversion,
  add a ? in front of leading whitespace to make it meta again.

* The ?-quantifier on captures in regexes currently binds the capture
  slot to a List containing either zero or one Match objects; i.e., it
  is equivalent to ** 0..1.  In the future, the ?-quantifier will
  bind the slot directly to a captured Match or to Nil.  Existing code
  can manage the transition by changing existing ?-quantifiers to
  use ** 0..1, which will continue to return a List of matches.

There are some key features of Perl 6 that Rakudo Star does not
yet handle appropriately, although they will appear in upcoming
releases.  Some of the not-quite-there features include:

  * macros
  * threads and concurrency
  * Unicode strings at levels other than codepoints
  * interactive readline that understands Unicode
  * non-blocking I/O
  * much of Synopsis 9

There is an online resource at http://perl6.org/compilers/features 
that lists the known implemented and missing features of Rakudo Star
2012.08 and other Perl 6 implementations.

In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are
many that we've missed.  Bug reports about missing and broken
features are welcomed at rakudo...@perl.org.

See http://perl6.org/ for links to much more information about 
Perl 6, including documentation, example code, tutorials, reference
materials, specification documents, and other supporting resources.
A draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf 
in the release tarball.

The development team thanks all of the contributors and sponsors
for making Rakudo Star possible.  If you would like to contribute,
see http://rakudo.org/how-to-help, ask on the perl6-compiler@perl.org
mailing list, or join us on IRC #perl6 on freenode.

[0] https://github.com/rakudo/rakudo/blob/nom/docs/announce/2012.08
[1] http://github.com/rakudo/rakudo
[2] http://parrot.org/

Re: How to get Rakudo for Windows

[Patrick R. Michaud]

On Tue, Aug 14, 2012 at 04:46:27PM +0300, Gabor Szabo wrote:
 hi,
 
 probably it would be nice if on http://rakudo.org/how-to-get-rakudo/
 it was mentioned
 where can people get the msi windows installer from?

Rakudo Star is currently available from github at 
http://github.com/rakudo/star/downloads/ .

This location includes both the source tarball and the Windows 
installer.  If/when we start creating .deb/.rpm packages for 
Rakudo Star, I would expect them to appear here also.

If we need something more structured for Rakudo Star downloads
than the simple GitHub download page, I guess we should start
building and maintaining a download page on rakudo.org
that then links to the latest download files individually on 
GitHub.  (I'm not particularly fond of using rakudo.org's bandwidth
for serving up the actual download files.)

Pm

Re: Test.pm function not returning truth

[Patrick R. Michaud]

On Thu, Jul 12, 2012 at 08:31:38AM +0300, Gabor Szabo wrote:
 Hi,
 
 I looked at lib/Test.pm and noticed that most (if not all) of the
 functions have
 some time measuring code in them and they return a timestamp instead
 of the truth value.
 
 Would it be ok if I changed that so they will always return true/false?

+1

Pm

Re: [perl #113992] [BUG][STAR] Cygwin build of parrot for rakudo star fails because of missing phony.exe

[Patrick R. Michaud]

On Wed, Jul 04, 2012 at 06:22:32PM -0700, Ron Schmidt via RT wrote:
  
  http://ftp.parrot.org/releases/devel/4.5.0/parrot-4.5.0.tar.gz
  
  If you can explode this tarball and build Parrot under Cygwin then
  I agree it's a Star issue.  Otherwise, I'd want to get an upstream
  fix from Parrot (unless they refuse, at which point we'll make
  a workaround in Star somehow).
 
 Well I unpacked the tarball and parrot built OK under cygwin.  I also 
 noticed that phony appeared before phony.exe in the packing order for 
 parrot and the opposite for rakudo star.  I asked on IRC and learned that 
 parrot was tarred on linux.

I'm guessing that it has to do with the packing order, then.
The script we use to build Rakudo Star doesn't do any sorting of
its MANIFEST, thus phony does end up coming after phony.exe .

So, if we just change that script to keep the MANIFEST sorted
before building the tarball (thus putting phony before phony.exe,
as Parrot does), that should avoid the problems with extracting 
files under Cygwin.

I'll send you a link to a new tarball to try out under Cygwin; 
if that works then we can close this ticket.  Thanks!

Pm

Re: [perl #113886] Re: no ICU lib loaded - rakudo and parrot issue

[Patrick R. Michaud]

On Thu, Jun 28, 2012 at 08:24:31AM -0700, Patrick R. Michaud wrote:
  Am 28.06.2012 14:31, schrieb Gabor Szabo:
  The following script generates an exception
  
  use v6;
  
  my %count;
  my $s = 'שלום';
  %count{$s} = 1;
  say $s;
  say %count.perl;
  
  no ICU lib loaded

This is now fixed in HEAD and will appear in the next release:

pmichaud@kiwi:~/p6/noicu$ ./perl6 -V | grep has_icu
parrot::has_icu=0
pmichaud@kiwi:~/p6/noicu$ cat rt113886.p6 
use v6;

my %count;
my $s = 'שלום';
%count{$s} = 1;
say $s;
say %count.perl;

pmichaud@kiwi:~/p6/noicu$ ./perl6 rt113886.p6 
שלום
(שלום = 1).hash

Pm

Re: Can't build NQP on a Raspberry Pi (without bodging)

[Patrick R. Michaud]

On Sun, Jul 01, 2012 at 07:42:37PM +0100, Nicholas Clark wrote:
  We all agree that we'd really like to see Rakudo's memory usage
  drop, especially on the build steps for the larger files (like 
  Perl6/Actions.pm and CORE.settings).  

I've now done some more testing and looking at build process
memory consumption -- more to come on this in a later message.
We may have a GC issue.

 I've no idea if this is a small change, or a big change, 
 but is it easy/viable/ useful to serialise the (in use) data 
 structures between the various stages:
 
 Stage parse: 163.188
 Stage syntaxcheck: 0.000
 Stage past: 0.000
 Stage optimize: 22.881
 Stage post: 55.730
 Stage pir: 25.610
 [...]
 
 If it's *easy*, it would be a win (I think) if the cost of memory usage of
 unused structures is higher than the cost of startup plus the cost of
 serialise/deserialise. And not a win if it's not.

I suspect it's not easy; I'd rather find out what's using
up all of the memory in the first place.

 Is there any Parrot or 6model equivalent of Devel::Size - ie a tool which
 attempts to work out the memory usage of everything reachable from an input
 object?

Not that I'm aware of.  That could be very useful.  Indeed, I
really wish Parrot had a way to return me a list of all of
the objects reachable from a given object by following the GC
mark algorithm.  Maybe Parrot does have such a thing and I'm
just unaware of it.  :-)

More soon,

Pm

Re: Can't build NQP on a Raspberry Pi (without bodging)

[Patrick R. Michaud]

On Thu, Jun 28, 2012 at 09:49:32PM +0100, Nicholas Clark wrote:
 So, I attempted to build Rakudo on my Raspberry Pi, expecting it to go wrong.
 It didn't quite pan out the way I expected.
 [...]
 It would be wonderful if Rakudo's memory usage would drop. I think that that's
 going to be easier than finding a faster swap device.

We all agree that we'd really like to see Rakudo's memory usage
drop, especially on the build steps for the larger files (like 
Perl6/Actions.pm and CORE.settings).  At the moment it takes a
lot of work and instrumentation (in all of Parrot, NQP, Rakudo)
to find out what's consuming all of the memory.  It's also
hard to know if things are being released/GC'd properly when
they're no longer being used (it's fairly easy in Parrot to 
end up with 'stray' references that cause large data structures 
to hang around much longer than you might expect).

We'll keep chipping away at it, though.  Maybe others some
some tools they can use to help us discover where the memory
is going...?

Pm

Re: [perl #66152] Rakudo consumes excessive resources for a simple loop

[Patrick R. Michaud]

On Mon, May 28, 2012 at 08:39:15AM -0700, Will Coleda via RT wrote:
 So, the original p5 code was:
 
 #!/usr/bin/perl -w
 my $i = 0;
 my @numbers;
 until ( $i == 10 ) {
   $numbers[$i] = $i;
   $i++;
 }

 [...]

 OP gave the following one-shot benchmark numbers:
 
 Perl5: ~0.07s to complete, uses 26KB RAM at completion.
 Rakudo Perl6: ~1m14s to complete, uses 1.4GB RAM at completion.

I find the RAM usage cited for the P5 case to be very suspect -- 
I don't know that an array of 100K integers can be held in 26KB of RAM.
I'll need more details about what is actually being measured here before 
addressing memory consumption used compared with p5 as bug.

On my system running perl 5.14.2, the P5 version above completes in 0.03 sec:

pmichaud@kiwi:~/p6/rakudo$ cat x.p5
#!/usr/bin/perl -w
my $i = 0;
my @numbers;
until ( $i == 10 ) {
  $numbers[$i] = $i;
  $i++;
}

pmichaud@kiwi:~/p6/rakudo$ time perl x.p5

real0m0.033s
user0m0.028s
sys 0m0.004s


 p6 code was:
 
 use v6;
 my Int $i = 0;
 my @numbers;
 until ( $i == 10 ) {
   @numbers[$i] = $i;
   $i++;
 }

As of 2012.05-94-g197e0bd, Rakudo now executes the above on my
system in about 5 seconds (versus 74 seconds in OP):

pmichaud@kiwi:~/p6/rakudo$ cat x.p6
use v6;

my Int $i = 0;
my @numbers;
until ($i == 10 ) {
@numbers[$i] = $i;
$i++;
}

pmichaud@kiwi:~/p6/rakudo$ time ./perl6 x.p6

real0m5.031s
user0m4.808s
sys 0m0.204s

Adding the Int constraint to $i is slightly unfair to the
p6 test, since it has to do more work (type checking) than the
p5 version did.  However, removing the Int on my system didn't
significantly improve the speed, although it might on other
systems.

Changing Int to int to use native ints for $i exposes a bug
with postfix:++ (to be filed as a different ticket).  
Working around that bug gives a loop that executes in 4 seconds:

pmichaud@kiwi:~/p6/rakudo$ cat z.p6
use v6;

my int $i = 0;
my @numbers;
until ($i == 10 ) {
@numbers[$i] = $i;
$i = $i + 1;
}

pmichaud@kiwi:~/p6/rakudo$ time ./perl6 z.p6

real0m4.000s
user0m3.788s
sys 0m0.188s

Based on the above, I'm declaring this ticket resolved.
I recognize that some people will still want the 100+ x
speed difference between p5 and p6 to be considered
a bug, but to me that starts to smack of an apples-to-oranges
comparison unless startup time needed for equivalent language 
features is included in the p5 case.

Also, this test is a little artificial; the canonical way 
to initialize @numbers in p6 would be:

pmichaud@kiwi:~/p6/rakudo$ cat w.p6
use v6;

my @numbers = 0..;

pmichaud@kiwi:~/p6/rakudo$ time ./perl6 w.p6

real0m0.475s
user0m0.364s
sys 0m0.104s

Resolving ticket.

Pm

[perl #113026] array iterator does not track a growing array

[Patrick R. Michaud via RT]

I suspect this bug may be related to #112716 
(https://rt.perl.org/rt3/Ticket/Display.html?id=112716); the .map() 
operation (which 'for' uses) tends to be a bit too eager in evaluating 
its invocant list.

I've taken both bugs and will work on a fix shortly.

Pm

[perl #111286] [BUG] Name capture happens in the presence of a quantifier but not in its absence in Rakudo

[Patrick R. Michaud via RT]

Now fixed in 0ed00f0 probably needs spectests to close ticket.

Thanks!

Pm

Re: [perl #112716] [BUG] lines() isn't lazy in Rakudo

[Patrick R. Michaud]

On Tue, May 01, 2012 at 09:11:22AM -0700, Carl Mäsak wrote:
 tadzik r: for $*IN.lines - $line { say $line.lc }
 p6eval rakudo 4c241c: OUTPUT«land der berge, land am strome, [...]
 goraki tadzik: masak: when I run either I don't get any output until
 I hit ctrl-d to end the input.
 masak goraki: let my try locally.
 masak my gosh, you're right!
 * masak submits rakudobug
 [...]
 masak lines() is supposed to be lazy.

Actually, as implemented lines() is already lazy:

pmichaud@kiwi:~/p6/rakudo$ ./perl6
 my @a := $*IN.lines().map( { .lc.say } ); 1;
1
 say @a[0]
HELLO
hello
True


The problem is actually in the .map code itself (I suspect
a misoptimization) -- when map is attempting to reify multiple
elements, it's batching up the required number of elements
before processing any of them:

 @a[3]
WORLD
GOODBYE
WORLD
world
goodbye
world
 

The problem line is in src/core/MapIter.pm:

my $munched := $!list.munch($argc * $count);

This causes all of the requested elements of the source $!list to
be reified before any of them are processed, thus .map isn't
properly lazy.  This line was added as an optimization to make
some .map operations faster, but lost some of the lazy aspects
of map (as well as other things).

The correct approach is to make .munch sufficiently performant
over repeated calls (avoiding repeated shifts of the
underlying list structures), which I plan to take care of 
shortly.

Pm

[perl #112364] [TODO] Parse Foo:: correctly in Rakudo

[Patrick R. Michaud via RT]

Now fixed in 84f4fd4:

class ABC { our sub xyz() { 'xyz' } };  say ABC::.WHAT
   Stash()

This ticket can be closed with sufficient spectests.

Pm

Re: [perl #112408] [BUG] Can't use END as a bareword hash key in Rakudo (but STD.pm6 allows it)

[Patrick R. Michaud]

On Thu, Apr 12, 2012 at 04:16:08AM -0700, Carl Mäsak wrote:
 That there's a parsing clash with block-less END phaser here goes
 without saying. But STD.pm6 resolves it somehow, and so should Rakudo.

I suspect it's a longest-token-matching (LTM) sort of thing, where 
STD.pm6's parser is able to longest match the 'END' + '=' and Rakudo's
parser only gets the 'END'.  (In other words, hopefully it'll be fixed 
when we switch to the new regex engine for compiling the grammar.)

Pm

[perl #112362] [BUG] Items which are arrays mistakenly give slices in hash or array lookup in Rakudo

[Patrick R. Michaud via RT]

Now fixed in 2c9f46f.  Needs spectests to close ticket.

Thanks,

Pm

Re: [perl #112288] [BUG] Non-deducible sequence ending in a Whatever star fails to give an error in Rakudo

[Patrick R. Michaud]

On Fri, Apr 06, 2012 at 03:53:11AM -0700, Nicholas Clark via RT wrote:
 On Thu Apr 05 14:56:03 2012, pmichaud wrote:
  On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote:
   moritz r: say ~(1, 2, 6 ... *)[10]
  
  For the moment, I'm going to argue Rakudo's behavior here as 
  correct, or at least consistent with the spec.
 
 I don't know how things map consistently for the general case, but
 from that example as a user I would be surprised and disappointed
 that the unable to deduce sequence isn't reported at compile
 time, as a compile time error. (Independent of the bug as reported,
 that element 10 is Nil).
 
 In that, as a programmer I would prefer to be told about errors at
 compile time, rather than having to rely on good coverage of my
 test suite to spot these errors before code gets into production.
 [...]

I agree compile-time detection of the above would be better.
Detecting the above case at compile time will likely be a 
function of constant folding built into the compiler; afaik the exact 
mechanism for handling that in Rakudo (and even in Perl 6) hasn't 
been completely worked out yet.  But even if that's available,
I somewhat wonder about something like:

my @a := (1, 2 ... 1), 10005, 10020 ... *;
my @b := 1, 2 ... 1, 10005, 10020 ... *;

In the above case, do we expect the compiler to compile-time
reify this complete list beyond the 10020 element to get to
the unable to deduce sequence error?  What tells the 
infix:... operator Hey, it's compile time, don't be lazy
and keep generating until you reach _this_ point?

Anyway, I think we'll be more productive to move the
constant-folding and compile-time detection issues to a
separate thread and/or ticket; for this ticket I'd prefer
to stick to the case where the sequence is being deduced
lazily at runtime and we're accessing elements beyond the
deduction failure.

Thanks!

Pm

Fwd: Re: [Pkg-parrot-devel] Parrot 4.0.0

[Patrick R. Michaud]

I just sent the message below to the parrot packagers mailing
list on Debian; I felt it was also worth sharing with p6c.
I'm certain there are people who disagree greatly with what 
I wrote -- and that's fine -- I just wanted to make sure my
current perspective on this topic was available to p6c as well.

Pm

- Forwarded message from Patrick R. Michaud pmich...@pobox.com -

Date: Sun, 8 Apr 2012 02:54:57 -0500
From: Patrick R. Michaud pmich...@pobox.com
To: Allison Randal alli...@parrot.org
Cc: pkg-parrot-de...@lists.alioth.debian.org
Subject: Re: [Pkg-parrot-devel] Parrot 4.0.0

On Sat, Apr 07, 2012 at 09:46:21AM -0700, Allison Randal wrote:
 On 04/07/2012 09:15 AM, Alessandro Ghedini wrote:
  
  Actually, I have uploaded [Parrot 4.0.0] just now (I was kind 
  of waiting for your response, though I've not been explicit). 
  I agree with you anyway, but I think (and hope) that the rakudo 
  (and nqp) release and development process will change as soon 
  as a 1.0 release will come near.
 
 That could be years in the future. [...]

...or years in the past.  

FWIW, within the Rakudo development team we don't think of ourselves 
as building up to an eventual 1.0 release -- we think of our 
1.0 release as having occurred sometime in the past (e.g., in summer 
2010).  As far as we're concerned, we're already in something
of a post-1.0 environment.

Many people can justifiably argue that Rakudo isn't stable or 
complete enough to be called 1.0 yet, and I can completely
understand that perspective.  But when we try to pin folks down
on what they would expect from 1.0 that Rakudo doesn't have now, 
we find that either (1) we've already achieved it,  (2) they're looking
for features that we expect to be evolving in the context of
a user community (e.g., an equivalent to CPAN, which I posit
is generally a post-1.0 development for *any* language), or 
(3) they expect things that are relatively unbounded, only
vaguely described, and/or not really compatible with ongoing 
Perl 6 evolutionary constraints.

Thus we largely conceive that Rakudo has already entered a phase 
of its lifetime where improved stability, completeness, and 
usability will come about through continued incremental evolution 
and increased adoption over time.  To me, that's a post-1.0 state
of affairs for a programming language.

So to return to the original thread: we don't have a 1.0
target in our future that might spur development in a particular
area such as release process.  Instead, like any product we tend 
to respond to the needs articulated by our client base.  This
client base definitely includes packagers.

If Rakudo's release and development process aren't supporting 
packagers well, we're very eager to making improvements quickly.  
Just keep in mind that nearly all of the release/development process 
we have in place today for Rakudo exists because of the current and
ongoing realities of developing for Parrot, and not because
we're lazy or uncaring about the packaging process. 

Pm

___
Pkg-parrot-devel mailing list
pkg-parrot-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-parrot-devel

- End forwarded message -

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
 On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote:
  What if we did something like bundling?
 
 Isn't this what Rakudo Star does? AFAICT the Star distribution is nothing 
 more
 than a bundle of rakudo + nqp + parrot + some Perl 6 modules, which may be 
 nice
 from a end user POV, but it's plain wrong from a distribution one. We (Debian)
 have different source packages for Parrot, Rakudo and NQP (which are managed 
 by
 two diffent teams) so that we can handle issues and changes separately without
 the need to rebuild all of them every time one needs to be changed.  

Unfortunately, aiui Parrot's current implementation requires that 
all of its downstream users (including Rakudo and NQP) must be 
rebuilt every time Parrot is changed.  Bytecode files created for one 
version of Parrot cannot be directly used with a later version of 
Parrot -- they must be regenerated.

Rakudo releases often require newer versions of Parrot, but that tends to
be because of changes to Parrot APIs or features also.  For example, 
Parrot 4.2.0 introduced an substantial API change that completely breaks 
downstream compatibility with previous versions of Parrot for Rakudo/NQP.
Historically, this sort of API breakage within Parrot has occurred at 
least once or twice per year -- at least often enough that it has been
nearly impossible for any Rakudo release to be buildable on two separate
Parrot supported releases.  (I suppose Rakudo could conceivably try to 
maintain separate development branches for each release of Parrot... 
but we're quite reluctant to do that.)

 Bundling them together would just make the Parrot and Rakudo packages 
 more dependant on each other... which is exactly what we are trying 
 to avoid. 

I totally agree the tight coupling between the packages is undesirable.
Any fix for this will likely have to come from Parrot, though -- afaict
Rakudo/NQP really can't do much about it on their own.

 Btw, this also applies to NQP bundling full source of
 libtommath and dyncall.

We'll work on removing the libtomath and dyncall sources from NQP 
tarballs, or make it very easy for NQP to ignore those sources.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 06:53:49PM +0200, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  Unfortunately, aiui Parrot's current implementation requires that 
  all of its downstream users (including Rakudo and NQP) must be 
  rebuilt every time Parrot is changed.  Bytecode files created for one 
  version of Parrot cannot be directly used with a later version of 
  Parrot -- they must be regenerated.
 
 This is true for newer upstream Parrot releases, but it happens that Debian
 packages require new uploads only to do Debian-specific changes (e.g. changes 
 to
 the packaging, small patches to the upstream code, ...) and the need to 
 rebuild
 Rakudo, NQP *and* Parrot just because I need to do a small change to the 
 packaging
 of, say, NQP is just putting more unnecessary burden on the Debian
 infrastructure (build daemons, ftp master, mirrors, ...).

I'm not quite able to follow here -- could you explain further or give
an example?  I mean, I understand how changes to NQP can affect
Rakudo, but I don't understand why/how it affects Parrot.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 07:32:55PM +0200, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 12:15:44PM -0500, Patrick R. Michaud wrote:
  I'm not quite able to follow here -- could you explain further or give
  an example?  I mean, I understand how changes to NQP can affect
  Rakudo, but I don't understand why/how it affects Parrot.
 
 Well, I was talking about Rakudo Star. If I have a rakudo-star source package,
 which includes the sources and builds packages for NQP, Rakudo and Parrot, 
 then
 if I need to do a change to the NQP packaging (which doesn't involve upstream
 sources updates) I'd also have to reupload the whole source package, which in
 turn means that not only NQP, but also Rakudo and Parrot would be rebuilt too.

Ah, I didn't realize you were referring to Rakudo Star, that's the likely
point of confusion.  

I fully agree that Rakudo Star is not at all Debian-packager-friendly as 
it exists now.  We still have some work to do on figuring out how to 
bundle/package Perl 6 modules and handle dependencies there -- Star has just
been our first forays into a full Perl 6 distribution.  It's always been
the plan and expectation that other Rakudo Perl 6 distribution and bundling 
systems will arise.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
 On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
  On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
   On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote: 
   Btw, this also applies to NQP bundling full source of
   libtommath and dyncall.
  
  We'll work on removing the libtomath and dyncall sources from NQP 
  tarballs, or make it very easy for NQP to ignore those sources.
  
  Thanks. As far as I'm concerned something simple as a Configure.pl option 
  (say,
  --use-system-libraries) or an environment variable would do
 
 Unfortunately from our point of view it's not that simple, because we
 have some patches to those libs; we'll try to push them upstream, but
 it'll take some time to do that and to get them all accepted.

Jonathan Worthington also tells me (and thus I'm passing along to
this list for information) that the libs bundled with nqp are 
statically linked in the executables, so at present there's no real 
version or installation conflict with any system versions 
of the same libraries.

We recognize this isn't ideal and will likely work to change it,
but apparently it's not as simple or trivial as just saying use 
the system-installed versions of the libraries.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sat, Apr 07, 2012 at 03:24:37PM -0700, Allison Randal wrote:
 These are things that Rakudo shouldn't care about. A bug-fix or
 performance enhancement in Parrot is good, but doesn't actually affect
 Rakudo's ability to build or run.

Sometimes it does.  See the flurry of difficulties we had last April
and May when Rakudo testing discovered that Parrot performance had 
declined by 100% over the previous several months (and Parrot
developers were completely unaware of it).

 Did the actual APIs change?  Different arguments required, or
 substantially different behavior so that there was absolutely no way
 Rakudo could run on both the old and new versions of Parrot? 

I can think of several instances where the APIs changed, such that
Rakudo could no longer run on an older Parrot or would require
substantial detection of which version of Parrot is being used
and change code generation or behavior accordingly.

 If so, then Parrot could be doing a better job of supporting 
 language development here, by preserving old APIs.

  One is due to getting a PAST improvement:
 [...]
 This is eager adoption of new features again. But, in this case I agree
 the fix is that PAST should move to NQP and out of the Parrot packages
 entirely. For one thing, having NQP depend on a library in Parrot that
 depends on NQP is nightmarish for packaging. 

FWIW, I don't think this circular dependency exists (Jonathan doesn't
think so either).  AFAIK, there's nothing in Parrot that has any sort 
of dependency on NQP.  (Note that there's a distinction between
nqp and nqp-rx; Parrot includes some nqp-rx stuff, but doesn't
make use of nqp.)

 Indeed, not enough detail there for much analysis. But, in general there
 is a difference between what you choose as your development process, and
 what you choose as your release process. It is very sensible to always
 test Rakudo against the latest versions of Parrot. But, that doesn't
 mean you can stop testing against older version of Parrot. The most
 important older versions to test against are the ones shipped in various
 distributions.
 [...]
 It would also be helpful if Rakudo and NQP adopted more strategies to
 keep the minimum required version as low as possible. Like soft
 launching new features so they're simply not available when they depend
 on a newer Parrot feature.

I will go back and test, but I'm willing to hazard a guess that
there are very few Rakudo releases that would be able to go very far back 
in Parrot's release history and still be functional, even with a sort of 
soft launching described here.  

For a recent and directly on topic example, take a look at 
https://github.com/perl6/nqp/commit/242f6e5997f6c454246fcf97b8a2a5d038d95931 ,
provided to NQP by a Parrot developer on March 5.  This commit means 
that subsequent versions of NQP and Rakudo are absolutely unable to
work with any version of Parrot prior to 4.2.0, because it's
an API change.  I also don't see any soft launch for this commit
that would make it easy for Rakudo/NQP to preserve access to
older versions of Parrot.

(Better would probably have been for Parrot to introduce a new opcode
with the correct order of arguments rather than changing the API of
an existing opcode, but that's not what happened here, and the API
change was not introduced at the request of Rakudo/NQP.  As far as
we can tell it came entirely from the Parrot development team.)

 I guess that raises the question for me of whether Rakudo is ready to be
 packaged. I don't have any trouble with Parrot packaging, but I do get a
 regular series of unusual requests from the Rakudo packagers. If the
 Rakudo project is totally focused on the use-case of downloading the
 source code or checking out from git and compiling from source, maybe
 it's just not ready for packaging.
 [...]
 I'm sure all the Rakudo packagers will agree with me that they'd really
 hate to remove it from Debian. But, if packaging isn't something Rakudo
 wants to support, then we shouldn't force the project into a different
 mindset. To give you an idea of what Debian packaging is looking for,
 take a skim through the upstream guide:

I think this line of thinking reaches the wrong conclusions.
What can be said with certainty is that for every Parrot release,
there is at least one corresponding Rakudo release that can make
use of that Parrot.  There's no reason to talk of Rakudo isn't ready
for packaging, because for any release of Parrot there is at least
one contemporaneous release of Rakudo that can make use of it.

What I suspect may be happening is that the Rakudo packagers
are being a little over-eager about trying to provide the
later versions of Rakudo, when there's not a packaged version
of Parrot that can support them.  In this case, Rakudo's official
suggestion would be for Rakudo packagers to stick to the most recent
version of Rakudo that is compatible with whatever release of Parrot
is available in that environment.  Since Parrot has a much slower
release and 

Re: sound distribution practices

[Patrick R. Michaud]

On Sat, Apr 07, 2012 at 07:12:19PM -0700, Allison Randal wrote:
 Patrick and I just chatted on the phone, here's a summary of the working
 scenario we reached:
 
 - Rakudo will deliver a Rakudo release for each supported (stable)
 Parrot release, a few days after the Parrot release.
 
 - Debian will package each supported release of Parrot.
 
 Debian packages for Rakudo will either:
 
 - Rebuild the old Rakudo packages on the new Parrot packages (since the
 old compiled bytecode, etc won't work on a different version of Parrot), or
 
 - Package the new version of Rakudo at exactly the same time as the new
 version of Parrot. Define the version requirements so tightly (=) that
 the Rakudo packages require exactly one version of Parrot.
 
 The first alternative is better, and will be the first preference. But
 it needs stable APIs from Parrot, so old Rakudo packages consistently
 work on newer versions of Parrot. This is mostly working, but the
 exceptions are pain points for packaging (we've got one coming up for 4.3).

Because Parrot bytecode is incompatible (both forward and
backward) between Parrot releases, doesn't the first alternative
also require the Rakudo package's requirements to be bound
tightly (=) to exactly one version of Parrot?

(I'm mainly seeking to improve/confirm my understanding of packaging
issues here.)

Pm

Re: [perl #112288] [BUG] Non-deducible sequence ending in a Whatever star fails to give an error in Rakudo

[Patrick R. Michaud]

On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote:
 moritz r: say ~(1, 2, 6 ... *)[10]
 p6eval rakudo 4373f0: OUTPUT«␤»
 moritz eeks
 moritz no, that particular thing isn't in RT
 * masak submits rakudobug

For the moment, I'm going to argue Rakudo's behavior here as 
correct, or at least consistent with the spec.

The sequence (1, 2, 6 ... *)  produces a list with
four elements:  1, 2, 6, and a Failure object containing
unable to deduce sequence.  This list is then asked for
its tenth element, which is Nil (because it's beyond the end
of the list), which is what is stringified and printed.

Since the Failure object is never used, its associated
exception is never thrown.

I suppose one could argue that a ... * sequence should produce
a non-terminating list of Failure objects; I may see if that
works out.

Along similar lines, the other mostly eager forms of trying 
to obtain the Failure end up not working because the ... * part 
of the sequence signals treat as potentially infinite at this
point, which pre-empts the mostly-eagerness.  

I agree that in most cases a mostly eager operation on a
infinite list should probably go ahead and reify a few terms
from the sequence first, rather than stopping immediately
(e.g. with '...') upon encountering it.  But I haven't found
a good bright-line rule for handling this in the general case,
nor do the Synopses have any good hints about it yet.

Pm

[perl #112216] slicing a string with inifinite ranges gives LTA error message

[Patrick R. Michaud via RT]

On Tue Apr 03 01:24:47 2012, moritz wrote:
 10:23  timotimo r: say foo[1..*]
 10:23 +p6eval rakudo 8ead1e: OUTPUT«Method 'gimme' not found for 
 invocant of
  class 'Str'␤  in method postcircumfix:[ ] at
  src/gen/CORE.setting:1147␤  in block anon at
  /tmp/1ZiRf7yMZW:1␤␤»


Now fixed in 1bbf9eb, needs spectests to close ticket.

Thanks!

Pm

[perl #111978] [BUG] ?^1 gives True in Rakudo

[Patrick R. Michaud via RT]

Now fixed in b1acd74.  Needs spectest coverage to close ticket.

Thanks!

Pm

[perl #111646] Arity counting mis-treats slurpy and capture parameters

[Patrick R. Michaud via RT]

Now fixed in 69920db585.

 say infix:~.arity
0
 say infix:~.count
Inf
 say a b c d.reduce(infix:~)
abcd

Ticket can be closed when we have appropriate spectests.

Thanks!

Pm

[perl #111848] [BUG] The storage strategy for arrays is weird in Rakudo

[Patrick R. Michaud via RT]

The speed of Array vs. Hash element access is partially addressed by 
commit c10792f8.  Before this commit, each Array element access via 
.at_pos($pos) resulted in an expensive call to self.exists($pos) for 
each access, whereas Hash element accesses via .at_key($key) were 
able to use nqp::existskey() directly.  This patch uses nqp::existspos() 
to hotpath the detection of existing elements and avoids calls to 
self.exists($pos) when the Array is already fully reified.  

For the benchmark given in RT #111848, this resulted in a ~25%
speedup for array element accesses, and brings it to within 5% of Hash
element access times.  (At present Array element accesses still have
more overhead at the PIR level than Hash element accesses due to
laziness considerations and boundary checks.

I'm still looking into the two layers of nextiter part; I agree
it's somewhat surprising but I'm not convinced it's suboptimal
within the current context of how we handle/store constant lists.
For the array assignment Rakudo has to do iteration at some point in
order to bring the elements into the top-level items part; it's
simply choosing to do it at the time of Array element access instead
of at the point of the assignment.  

Given that the ticket refers to suboptimality, it's hard to know
when it should be closed.  If masak++ or someone else feels that
this reply adequately addresses the issues for now, I'm fine with
it being resolved now, or if we want to leave it open pending further
discussion/resolution of the two nextiter layer issue, I'm fine
with that also.

Pm

Re: [perl #111796] Rakudo regex regression

[Patrick R. Michaud]

On Fri, Mar 16, 2012 at 03:51:49PM -0400, Will Coleda wrote:
 In this case, if you build rakudo with --gen-parrot, you'll whatever
 the recommended version for that release of rakudo.

...or any later version, if the parrot/ subdirectory is a git repository.

 So, you could remove the ./install directory before each bisect run
 and get a version of parrot that will at least probably work with that
 version of rakudo.

Since --gen-parrot accepts later releases, you might need to
remove or update the parrot/ directory as well.  And nqp/ is
similarly implicated as well.  

So, a true rebuild likely means doing something like:

( cd nqp; git checkout $(cat ../tools/build/NQP_REVISION) )
perl Configure.pl --gen-parrot=$(cat nqp/tools/build/PARROT_REVISION)

Pm