Re: S05 and S29 may conflict on behavior of $string.match(/pat/)

[Chris Davaz]

Thanks for clarifying however I'm still unsure what a Perl 6 user
should expect to get back from running $string.match(/pat/). This is
the ""one
high-level call to the .match method" yes? So it should be returning a
List of Str (or List of Match in case of capture groups), is this
correct? I ask because in the current Rakudo implementation it returns
the Match object (what I would expect from the "one low-level run of
the regex engine").

Best Regards,
-Chris

On Thu, Sep 18, 2008 at 11:52 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote:
> : I'm trying to pin down what $string.match(/pat/) should be returning.
> :
> : >From S05:
> :
> : Under "Return values from match objects"
> : "A match always returns a Match object..."
> :
> : >From S29:
> :
> : Under the definition of Str.comb
> :
> : Saying
> :
> : $string.comb(/pat/, $n)
> :
> : is equivalent to
> :
> : $string.match(rx:global:x(0..$n):c/pat/)
> :
> : [ ...and later... ]
> :
> : "If there are captures in the pattern, a list of Match objects (one
> : per match) is returned instead of strings."
> :
> : Which implies that $string.match(/pat/) should indeed return a List of
> : Str and $string.match(/pat_with_groups/) should return a List of
> : Match.
> :
> : I expected the S29 definition when first approaching $string.match I
> : feel it is more intuitive than what happens with S05. Could someone
> : clarify what the behavior should be?
>
> S05 is using a different definition of "match".  In S05 it means
> more like "one low-level run of the regex engine" rather than "one
> high-level call to the .match method".  In other words, the .match
> method can do multiple matches.
>
> Larry
>

Re: New Parrot mailing list

[James E Keenan]

Allison Randal wrote:
The new Parrot mailing list (replacing perl6-internals/parrot-porters) 
is <[EMAIL PROTECTED]>. If you were subscribed to the old 
list, you're now subscribed to the new list. If you were a digest 
subscriber to the old list, you're now a digest subscriber to the new list.


More information about the list and public archives are available at:

http://lists.parrot.org/mailman/listinfo/parrot-dev



Does this mean that the newsgroup perl.perl6.internal on nntp.perl.org 
is dying as well?


If so, I think that will be a real loss.  I vastly prefer the news 
interface to a mailing list for following such groups.


(And I wish this had been discussed publicly before this announcement!)

kid51

Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc

[chromatic]

On Thursday 18 September 2008 12:03:19 NotFound wrote:

> On Thu, Sep 18, 2008 at 8:14 PM, chromatic <[EMAIL PROTECTED]> wrote:

> > The comment helps, but defining these magic numbers as magic constants
> > might be even clearer (but please keep the comment).

> I think that setting a constant is sort of establishing it as a
> documented value, and I don't think that document who many digits can
> have the hex representation of flags is good, or it must be done in a
> file other than the one that defines the flags.

Even #define-ing them locally to the function has readability value.  I want 
the code to be so blindingly obvious to read that if there's a problem, it's 
apparent without having to turn magic numbers back into their meanings.  The 
compiler doesn't care either way.

> >> +PARROT_ASSERT(strlen(buf) + strlen(s) < bufsize);
> >> +strcat(buf, s);
> >
> > That only helps with debug builds; if there are possible inputs we won't
> > discover in our testing, we might as well make this an unconditional test
> > and throw an exception if something goes wrong here.  IMCC is
> > user-facing, so I want to be paranoid.
>
> After some thinking I must agree. I hope that this code will be
> refactored before 1.0, but we can't be sure.

I sort of hope IMCC can vanish before 1.0, or at least find a small army of 
heavily motivated cage cleaners who merge it with pirc.

> The problem is that I don't know what severity must be used, and if it
> the exception must be catched by the main imcc entry points or let it
> propagate to the caller. Maybe all imcc fail conditions must throw
> exceptions, for the benefit of load_bytecode invocations.

I don't think anyone's asked that question yet (at least no one has answered 
it yet), so let's not let that get in the way of adding an exception here 
now.  Unifying IMCC exceptions with Parrot exceptions does seem valuable 
(though convincing IMCC not to leak memory under those circumstances... I'm 
going to lie down now for a while).

-- c

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[Geoffrey Broadwell]

On Thu, 2008-09-18 at 10:28 -0700, jerry gay wrote:
> On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud <[EMAIL PROTECTED]> 
> wrote:
> > On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote:
> >> what some refer to as "traits", perl 6 calls "roles".

The Perl 6 name is a better, more natural and self-describing name.
Larry has a gift for naming, and he puts a lot of effort into making
names obvious.  I think it's a mistake to ignore that, just because
Larry didn't design all of the major dynamic languages himself.

> > Other languages have adopted the Perl shortname of "hash" as well,
> > including Ruby and this odd little creature known as "Parrot".  Perhaps
> > we should rename Parrot's "Hash" class to "AssociativePMCArray"?  1/2 ;-)

I personally agree that 'hash' is by far the better name.  But to be
fair, it helps that 'hash' is one of the basic data structures taught to
every CS student freshman year 

> >> we should call gather and take by their proper names where they're
> >> defined. "aggregating coroutine" is more precise and descriptive than
> >> is "gather",

If you had no idea what an 'aggregating coroutine' was, would your first
guess be something that acts as a generator for a lazy list?  Really?
And you'd get that faster than guessing what 'gather' might mean?  Do
you think the same is true of someone without a CS degree and/or a
rather advanced background?

> >> however "gather" is much easier to say in polite company,
> >> and is therefore a better name to use at the language level.

We should not have the implementation and the HLLs use utterly different
terminology for the same concept (unless every HLL uses different
terminology and they all suck) -- that will just confuse contributors
who don't do full time core work.  It is certainly proper for the core
and the HLLs to use different terminology for things that are similar
but different, but in this case we're talking about the implementation
of the HLL concept -- it should use the same terminology.

Of course, I'm fine with using slightly more verbosity in the core,
because it will be more rarely looked at and therefore needs to optimize
more for clarity than stroke reduction.

> > By this reasoning, we should also change the other exceptions:
> >
> >.CONTROL_RETURN   =>   .CONTROL_SUB_RETURN   (or .CONTROL_SUB_EXIT)
> >.CONTROL_BREAK=>   .CONTROL_LOOP_EXIT
> >.CONTROL_CONTINUE =>   .CONTROL_LOOP_NEXT
> >
> > and perhaps add .CONTROL_LOOP_REPEAT there as well.  Note that I'm not at
> > all opposed to this -- if we're going to do it for one, we really
> > ought to do it for all.
> >
> agreed. precision is of little benefit unless it's consistent across
> related functionality.

Along the same lines, how about one of the following pairs?

  * .CONTROL_GENERATOR_GATHER and .CONTROL_GENERATOR_TAKE
  * .CONTROL_GENERATOR_SINK   and .CONTROL_GENERATOR_SOURCE
  * .CONTROL_GATHER_SINK  and .CONTROL_GATHER_SOURCE
  * .CONTROL_GATHER_LIST  and .CONTROL_YIELD_LIST_ELEMENT(S)
  * .CONTROL_LIST_GATHER  and .CONTROL_LIST_YIELD
  * .CONTROL_LAZY_GATHER  and .CONTROL_LAZY_YIELD
  * .CONTROL_LAZY_LIST_GATHER and .CONTROL_LAZY_LIST_YIELD

(Or something similar; my naming fu is off today.)


-'f

Re: [perl #51262] [BUG] Segfault in pdump

[NotFound]

Changed in r31328: now string DATA use string_escape_string and
delimit with double quotes, avoiding the need to a special case for
empty strings and giving less problematic results with non ascii
encodings and control characters.

-- 
Salu2

Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc

[NotFound]

On Thu, Sep 18, 2008 at 8:14 PM, chromatic <[EMAIL PROTECTED]> wrote:

>> -char* buf = mem_allocate_n_typed(5*n+1, char *);
>> +/* Assumptions:
>> + * Flags has no more than 3 hex digits
>> + * Plus 0x and , gives 6 char for arg
>> + * 4 more for: "( , )", and
>> + * 1 more for C string 0 delimiter
>> + * Last item has no , but we can forget that to avoid
>> + * to have to check for 0 args.
>> + */
>> +unsigned int bufsize = 6 * n + 5;
>> +char * buf = mem_allocate_n_typed(bufsize, char);
>>
>>  strcpy(buf, "\"(");
>>  for (i = 0; i < n; i++) {
>
> The comment helps, but defining these magic numbers as magic constants might
> be even clearer (but please keep the comment).

I think that setting a constant is sort of establishing it as a
documented value, and I don't think that document who many digits can
have the hex representation of flags is good, or it must be done in a
file other than the one that defines the flags.

>> +PARROT_ASSERT(strlen(buf) + strlen(s) < bufsize);
>> +strcat(buf, s);

> That only helps with debug builds; if there are possible inputs we won't
> discover in our testing, we might as well make this an unconditional test and
> throw an exception if something goes wrong here.  IMCC is user-facing, so I
> want to be paranoid.

After some thinking I must agree. I hope that this code will be
refactored before 1.0, but we can't be sure.

The problem is that I don't know what severity must be used, and if it
the exception must be catched by the main imcc entry points or let it
propagate to the caller. Maybe all imcc fail conditions must throw
exceptions, for the benefit of load_bytecode invocations.

-- 
Salu2

Re: [perl #58828] Make calleable &-sigil parameters work in rakudo

[ajr]

>>
>> OH HAI...you can haz fix in r31228. Plz I can haz spectests so we avoidz
>> regreshuns?
>
> IF u sai so. U can haz tesz in r31229.
>
> KTXBAI,
>

Can this meme be exorcised before the contamination spreads?


--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com

Re: [svn:parrot] r31230 - in trunk: compilers/imcc src src/pmc

[chromatic]

On Thursday 18 September 2008 08:42:46 [EMAIL PROTECTED] wrote:

> Author: julianalbo
> Date: Thu Sep 18 08:42:43 2008
> New Revision: 31230
>
> Modified:
>trunk/compilers/imcc/pcc.c
>
> Log:
> miscellaneous fixes
>
> Modified: trunk/compilers/imcc/pcc.c
> ===
>=== --- trunk/compilers/imcc/pcc.c (original)
> +++ trunk/compilers/imcc/pcc.cThu Sep 18 08:42:43 2008
> @@ -211,7 +211,16 @@
>  int i, flags;
>  char s[16];
>  SymReg ** const regs  = mem_allocate_n_zeroed_typed(n + 1, SymReg *);
> -char* buf = mem_allocate_n_typed(5*n+1, char *);
> +/* Assumptions:
> + * Flags has no more than 3 hex digits
> + * Plus 0x and , gives 6 char for arg
> + * 4 more for: "( , )", and
> + * 1 more for C string 0 delimiter
> + * Last item has no , but we can forget that to avoid
> + * to have to check for 0 args.
> + */
> +unsigned int bufsize = 6 * n + 5;
> +char * buf = mem_allocate_n_typed(bufsize, char);
>
>  strcpy(buf, "\"(");
>  for (i = 0; i < n; i++) {

The comment helps, but defining these magic numbers as magic constants might 
be even clearer (but please keep the comment).

> @@ -252,7 +261,8 @@
>
>  if (i < n - 1)
>  strcat(s, ",");
> -strcat(buf, s); /* XXX check avail len */
> +PARROT_ASSERT(strlen(buf) + strlen(s) < bufsize);
> +strcat(buf, s);
>  }
>
>  strcat(buf, ")\"");

That only helps with debug builds; if there are possible inputs we won't 
discover in our testing, we might as well make this an unconditional test and 
throw an exception if something goes wrong here.  IMCC is user-facing, so I 
want to be paranoid.

-- c

Re: [perl #58726] [PATCH] add the option "encoding" to Configure.pl

[NotFound]

>> Can you explain a bit more about the rationale for adding this option to
>> Configure.pl?
>>
> I think I is necessary to tell parrot to work on a computer with utf-8 
> encoding
> also with the same encoding, so that for example the following PASM-code 
> works:
>
> set S0, "Ö123\n"

That code is not supposed to work. Encoding and charset must be specified.

Is not good that pir or pasm code meaning be dependent of locale
specifics of the system.

Also in several operating systems is not the computer who is working
with some charset and encoding or other, is each process (depending of
user settings on locale env vars, for example). So establishing an
immutable global default is not a good idea.

-- 
Salu2

Re: New Parrot mailing list

[Patrick R. Michaud]

On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote:
> We'll likely end up with messages scattered between both lists for a 
> little while, but the perl6-internals/parrot-porters addresses are 
> deprecated and will be disabled after a sensible deprecation cycle (and 
> after the automatic RT posts have been shifted to parrot-dev).

Will we also be able to get svn commits to the new mailing list, 
or at least to *a* mailing list?

> The new mailing list will not automatically update tickets in the RT 
> queue, for that CC <[EMAIL PROTECTED]> on the message.

Wouldn't it be possible to have the new mailing list manager 
check for [perl #n] in the message subject and automatically forward
it (controlling for loops as appropriate)?  

Or, if the MLM can't do it, then perhaps subscribe an address to
parrot-dev that performs this action for us?

Pm

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[jerry gay]

On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote:
>> On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> 
>> wrote:
>> > On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
>> >> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy
>> >> > as 'gather' and 'take', but they're more meaningful to a broader
>> >> > audience, which may help the feature spread.
>> >
>> > I don't buy this.  The Perl 6 terms are well chosen, and as soon as you
>> > know what they mean in the context of programming, you won't forget.
>> > The other versions ... well, let's leave it at "easy to forget".  (OK,
>> > one more thing -- the word "coroutine" scares people.  "Gather" does
>> > not.)
>> >
>> >> I'm rather hoping and expecting that "gather" and "take" become
>> >> the meaningful names for this feature, much like "grep" started
>> >> out as a Unix shell command but is now the language-agnostic term for
>> >> "extract things from a list matching a pattern".
>> >
>> > Now *this* I agree with.  The first system to make a feature standard
>> > gets first try at standardizing the name.  If they've chosen the name
>> > well, there's a decent chance it will stick.
>>
>> what some refer to as "traits", perl 6 calls "roles".
>>
>> what some refer to as "associative arrays", perl calls "hashes".
>> [...]
>> we need to be precise in naming constructs, rather than using common names.
>> scientists call a chanterelle mushroom by its proper name,
>> "Cantharellus cibarius".
>
> Other languages have adopted the Perl shortname of "hash" as well,
> including Ruby and this odd little creature known as "Parrot".  Perhaps
> we should rename Parrot's "Hash" class to "AssociativePMCArray"?  1/2 ;-)
>
>> we should call gather and take by their proper names where they're
>> defined. "aggregating coroutine" is more precise and descriptive than
>> is "gather", however "gather" is much easier to say in polite company,
>> and is therefore a better name to use at the language level.
>
> By this reasoning, we should also change the other exceptions:
>
>.CONTROL_RETURN   =>   .CONTROL_SUB_RETURN   (or .CONTROL_SUB_EXIT)
>.CONTROL_BREAK=>   .CONTROL_LOOP_EXIT
>.CONTROL_CONTINUE =>   .CONTROL_LOOP_NEXT
>
> and perhaps add .CONTROL_LOOP_REPEAT there as well.  Note that I'm not at
> all opposed to this -- if we're going to do it for one, we really
> ought to do it for all.
>
agreed. precision is of little benefit unless it's consistent across
related functionality.

~jerry

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[Patrick R. Michaud]

On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote:
> On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
> >> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy
> >> > as 'gather' and 'take', but they're more meaningful to a broader
> >> > audience, which may help the feature spread.
> >
> > I don't buy this.  The Perl 6 terms are well chosen, and as soon as you
> > know what they mean in the context of programming, you won't forget.
> > The other versions ... well, let's leave it at "easy to forget".  (OK,
> > one more thing -- the word "coroutine" scares people.  "Gather" does
> > not.)
> >
> >> I'm rather hoping and expecting that "gather" and "take" become
> >> the meaningful names for this feature, much like "grep" started
> >> out as a Unix shell command but is now the language-agnostic term for
> >> "extract things from a list matching a pattern".
> >
> > Now *this* I agree with.  The first system to make a feature standard
> > gets first try at standardizing the name.  If they've chosen the name
> > well, there's a decent chance it will stick.
>
> what some refer to as "traits", perl 6 calls "roles".
> 
> what some refer to as "associative arrays", perl calls "hashes".
> [...]
> we need to be precise in naming constructs, rather than using common names.
> scientists call a chanterelle mushroom by its proper name,
> "Cantharellus cibarius".

Other languages have adopted the Perl shortname of "hash" as well, 
including Ruby and this odd little creature known as "Parrot".  Perhaps 
we should rename Parrot's "Hash" class to "AssociativePMCArray"?  1/2 ;-)

> we should call gather and take by their proper names where they're
> defined. "aggregating coroutine" is more precise and descriptive than
> is "gather", however "gather" is much easier to say in polite company,
> and is therefore a better name to use at the language level.

By this reasoning, we should also change the other exceptions:

.CONTROL_RETURN   =>   .CONTROL_SUB_RETURN   (or .CONTROL_SUB_EXIT)
.CONTROL_BREAK=>   .CONTROL_LOOP_EXIT
.CONTROL_CONTINUE =>   .CONTROL_LOOP_NEXT

and perhaps add .CONTROL_LOOP_REPEAT there as well.  Note that I'm not at
all opposed to this -- if we're going to do it for one, we really
ought to do it for all.

> a related point: wherever these constructs are defined, they need to
> be documented. you may think "CONTROL_RETURN" is obviously for
> "return" statements, but many will find it quite strange that "return"
> is an Exception at all.

Agreed that we should document them all somewhere.  I vote that we 
do it in the Exceptions PDD.  :-P

Pm

Re: Made some fixes to split on a regex and moved from Str.pir to any-str.pir

[Moritz Lenz]

Chris Davaz wrote:
> Sorry forgot to put the method in alphabetical order, here you go.

Thanks, applied as r31234. It's still masked by Str.split(Str), which
should be moved to builtins/any-str.pir as well, but that's the job for
another patch.

1234.split(/3/) works right now, so it's even a bit usable right now ;-)

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: Made some fixes to split on a regex and moved from Str.pir to any-str.pir

[Chris Davaz]

Sorry forgot to put the method in alphabetical order, here you go.

On Fri, Sep 19, 2008 at 12:36 AM, Chris Davaz <[EMAIL PROTECTED]> wrote:
> Got rid of "tempstr" and now returns the entire string on a non-match.
>
Index: src/builtins/any-str.pir
===
--- src/builtins/any-str.pir	(revision 31220)
+++ src/builtins/any-str.pir	(working copy)
@@ -71,7 +71,6 @@
 .return(retv)
 .end
 
-
 =item index()
 
 =cut
@@ -173,6 +172,42 @@
 .return ($P0)
 .end
 
+=item split(/PATTERN/)
+
+Splits something on a regular expresion
+
+=cut
+
+.sub 'split' :method :multi(_, 'Sub')
+.param pmc regex 
+.local pmc match
+.local pmc retv
+.local int start_pos
+.local int end_pos
+
+$S0 = self
+retv = new 'List'
+start_pos = 0
+
+match = regex($S0)
+if match goto loop
+retv.'push'($S0)
+goto done
+
+  loop:
+match = regex($S0, 'continue' => start_pos)
+end_pos = match.'from'()
+end_pos -= start_pos
+$S1 = substr $S0, start_pos, end_pos
+retv.'push'($S1)
+unless match goto done
+start_pos = match.'to'()
+goto loop
+
+  done:
+.return(retv)
+.end
+
 =item substr()
 
 =cut

Made some fixes to split on a regex and moved from Str.pir to any-str.pir

[Chris Davaz]

Got rid of "tempstr" and now returns the entire string on a non-match.
Index: src/builtins/any-str.pir
===
--- src/builtins/any-str.pir	(revision 31220)
+++ src/builtins/any-str.pir	(working copy)
@@ -71,7 +71,42 @@
 .return(retv)
 .end
 
+=item split()
 
+Splits something on a regular expresion
+
+=cut
+
+.sub 'split' :method :multi(_, 'Sub')
+.param pmc regex 
+.local pmc match
+.local pmc retv
+.local int start_pos
+.local int end_pos
+
+$S0 = self
+retv = new 'List'
+start_pos = 0
+
+match = regex($S0)
+if match goto loop
+retv.'push'($S0)
+goto done
+
+  loop:
+match = regex($S0, 'continue' => start_pos)
+end_pos = match.'from'()
+end_pos -= start_pos
+$S1 = substr $S0, start_pos, end_pos
+retv.'push'($S1)
+unless match goto done
+start_pos = match.'to'()
+goto loop
+
+  done:
+.return(retv)
+.end
+
 =item index()
 
 =cut


split.p6
Description: Binary data

Re: Should $.foo attributes without "is rw" be writable from within the class

[TSa]

HaloO,

Carl Mäsak wrote:

I really like all the replies I got to this; thank you Moritz,
Jonathan, TSa, Larry, John and Damian.


It was a pleasure to be useful.


From the feedback I received, I will now do the following:


1. Remove "is rw" from all attributes that aren't supposed to be
writable from outside the class.

2. Start using $!foo consistently in methods, for both read and write accesses.


From a best practice POV consider

   class A
   {
   has $.foo = "A";
   has $!bar = "A";

   method blahh()
   {
  say $.foo ~ $!foo ~ $!bar;
   }
   }
   class B is A
   {
   has $.foo = "B";
   has $!bar = "B";
   }

   my $a = A.new;
   my $b = B.new;

   say $a.blahh; # prints AAA
   say $b.blahh; # prints BAA, right?

Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor? And of course the example shows that $!foo in
blahh is not derivation friendly. Or am I getting things wrong and
there can be only one $!foo and $!bar in the namespace of the objects
created from A and B? That is the declarations in B are superfluous
if not outright wrong? Well, or they only affect the generated
constructor and the storage location is shared? The latter would
nicely contrast them to non twigil attributes in the form 'has $foo'.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: How to define a new value type?

[TSa]

HaloO,

John M. Dlugosz wrote:

TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:

Is it generally foreseen that an object knows about the containers
it is stored in? 
Yes.  But it is not generally the case that this is the same container 
as the caller is holding.  Detailed specifications of the meaning of 
'read-only', 'rw', 'copy', and 'ref' and the binding semantics thereof 
need to address this, and address the concerns of efficient 
implementations.


I meant the general 1:n relation of value to containers not the
relation of outer and inner containers in sub calls. I think that
back refs from the value to all containers is cumbersome and of
little practical value if the semantics of the language don't
require it. E.g. if the deletion of values were possible then all
containers holding the value need to be nulled. The back refs
need to be updated when a container receives a new value. It has
to detach from the former value and attach to the new one.

So again the question: are back refs from the value to the containers
required to implement Perl 6? I guess not.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[jerry gay]

On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
>> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy
>> > as 'gather' and 'take', but they're more meaningful to a broader
>> > audience, which may help the feature spread.
>
> I don't buy this.  The Perl 6 terms are well chosen, and as soon as you
> know what they mean in the context of programming, you won't forget.
> The other versions ... well, let's leave it at "easy to forget".  (OK,
> one more thing -- the word "coroutine" scares people.  "Gather" does
> not.)
>
>> I'm rather hoping and expecting that "gather" and "take" become
>> the meaningful names for this feature, much like "grep" started
>> out as a Unix shell command but is now the language-agnostic term for
>> "extract things from a list matching a pattern".
>
> Now *this* I agree with.  The first system to make a feature standard
> gets first try at standardizing the name.  If they've chosen the name
> well, there's a decent chance it will stick.
>
what's the difference between gather and aggregating coroutine?
lipstick.

but seriously, folks,

what some refer to as "traits", perl 6 calls "roles".

what some refer to as "associative arrays", perl calls "hashes".
but aren't hashes that funny key on your phone you type after you've
entered your credit card info? oh, right, that's "pound". huh? i
thought that's an outdated form of currency.
let's call it "octothorpe". wait, what? you store your dispatch table
in an octothorpe?

we need to be precise in naming constructs, rather than using common names.
scientists call a chanterelle mushroom by its proper name,
"Cantharellus cibarius".

we should call gather and take by their proper names where they're
defined. "aggregating coroutine" is more precise and descriptive than
is "gather", however "gather" is much easier to say in polite company,
and is therefore a better name to use at the language level.

a related point: wherever these constructs are defined, they need to
be documented. you may think "CONTROL_RETURN" is obviously for
"return" statements, but many will find it quite strange that "return"
is an Exception at all.

~jerry

Re: S05 and S29 may conflict on behavior of $string.match(/pat/)

[Larry Wall]

On Thu, Sep 18, 2008 at 06:11:45PM +0800, Chris Davaz wrote:
: I'm trying to pin down what $string.match(/pat/) should be returning.
: 
: >From S05:
: 
: Under "Return values from match objects"
: "A match always returns a Match object..."
: 
: >From S29:
: 
: Under the definition of Str.comb
: 
: Saying
: 
: $string.comb(/pat/, $n)
: 
: is equivalent to
: 
: $string.match(rx:global:x(0..$n):c/pat/)
: 
: [ ...and later... ]
: 
: "If there are captures in the pattern, a list of Match objects (one
: per match) is returned instead of strings."
: 
: Which implies that $string.match(/pat/) should indeed return a List of
: Str and $string.match(/pat_with_groups/) should return a List of
: Match.
: 
: I expected the S29 definition when first approaching $string.match I
: feel it is more intuitive than what happens with S05. Could someone
: clarify what the behavior should be?

S05 is using a different definition of "match".  In S05 it means
more like "one low-level run of the regex engine" rather than "one
high-level call to the .match method".  In other words, the .match
method can do multiple matches.

Larry

Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot

[NotFound]

I changed the fix in r31230 to allocate char instead of char *,
adjusted the formula for buffer size and added a comment explaining it
to lower the level of black magic, and added a check for each item,
dropping the XXX comment that asked for it.

I hope this is enough understanding of the error ;)

-- 
Salu2

Re: [perl #58970] Initial implementation of Str.split(Regex)

[Chris Davaz]

Here is the new patch for split on a regex. Testing it with:

say "theXbiggestXbangXforXtheXbuck".split(/X/).perl;
say "ab1cd12ef123gh".split(/\d+/).perl;
say "charsoup".split(/\<\/?.*?\>/).perl;

We get the following output:

["the", "biggest", "bang", "for", "the", "buck"]
["ab", "cd", "ef", "gh"]
["", "char", "", "soup", ""]

I'll upload a test to pugs later.

On Thu, Sep 18, 2008 at 3:33 PM, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> Chris Davaz wrote:
>> Ok, here it is without the change to "split on a string", and the test
>> passes.
>
> Yes, but on my machine now t/spec/S04-statements/gather.t produces a
> segmentation fault. I'll have to investigate if that is related to your
> patch or not.
>
> Also split behaves a bit strangely here:
>
>  > say 'ab23d4f5'.split(/\d+/).perl
>  ["ab", "", "", "d", "f", ""]
>  > say 'ab23d4f5'.split(/\d/).perl
>  ["ab", "", "d", "f", ""]
>
> (There are a few other oddities like the behaviour with a zero-width
> match, but that's only a minor issue).
>
>> Please apply this one and in the meantime I will see how we can
>> get the method signature right for split on a strong + not break reverse.
>
> --
> Moritz Lenz
> http://moritz.faui2k3.org/ |  http://perl-6.de/
>
Index: src/classes/Str.pir
===
--- src/classes/Str.pir	(revision 31220)
+++ src/classes/Str.pir	(working copy)
@@ -76,6 +76,35 @@
 .return(retv)
 .end
 
+# split a string on a regex
+.sub 'split' :method :multi(_, 'Sub')
+.param pmc regex 
+.local pmc match
+.local pmc tmpstr
+.local pmc retv
+.local int start_pos
+.local int end_pos
+
+$S0 = self
+retv = new 'List'
+start_pos = 0
+
+  loop:
+match = regex($S0, 'continue' => start_pos)
+end_pos = match.'from'()
+end_pos -= start_pos
+tmpstr = new 'Perl6Str'
+$S1 = substr $S0, start_pos, end_pos
+tmpstr = $S1
+retv.'push'(tmpstr)
+unless match goto done
+start_pos = match.'to'()
+goto loop
+
+  done:
+.return(retv)
+.end
+
 .sub lc :method
 .local string tmps
 .local pmc retv

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[Geoffrey Broadwell]

On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy  
> > as 'gather' and 'take', but they're more meaningful to a broader  
> > audience, which may help the feature spread.

I don't buy this.  The Perl 6 terms are well chosen, and as soon as you
know what they mean in the context of programming, you won't forget.
The other versions ... well, let's leave it at "easy to forget".  (OK,
one more thing -- the word "coroutine" scares people.  "Gather" does
not.)

> I'm rather hoping and expecting that "gather" and "take" become 
> the meaningful names for this feature, much like "grep" started 
> out as a Unix shell command but is now the language-agnostic term for
> "extract things from a list matching a pattern".

Now *this* I agree with.  The first system to make a feature standard
gets first try at standardizing the name.  If they've chosen the name
well, there's a decent chance it will stick.


-'f

Re: [perl #58828] Make calleable &-sigil parameters work in rakudo

[Moritz Lenz]

[EMAIL PROTECTED] via RT wrote:
> On Sat Sep 13 04:33:53 2008, masak wrote:
> 
> OH HAI...you can haz fix in r31228. Plz I can haz spectests so we avoidz
> regreshuns?

IF u sai so. U can haz tesz in r31229.

KTXBAI,

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #59006] stringifying Floats into PIR literals loses (a lot of) precision

[Will Coleda]

On Thu, Sep 18, 2008 at 9:13 AM, Patrick R. Michaud (via RT)
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Patrick R. Michaud
> # Please include the string:  [perl #59006]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=59006 >
>
>
> When generating PIR output (e.g., from the compiler tools), we
> often need to convert a Float value into an equivalent representation
> for PIR.



This sounds very much like partcl's need to support [set tcl_precision 0]


-- 
Will "Coke" Coleda

Re: [perl #58998] [TODO] remove underscores from numbers to make imcc happy

[Patrick R. Michaud]

On Thu, Sep 18, 2008 at 03:28:31AM -0700, [EMAIL PROTECTED] via RT wrote:
> On Thu Sep 18 00:49:59 2008, [EMAIL PROTECTED] wrote:
> > r31220:
> > > say 23_433
> > 23433
> > > say 23_433.4_4
> > error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
> > in file 'EVAL_13' line 12
> > 23
> > 
> > Obviously the underscores in the fractional part of the number needs to
> > be stripped by rakudo before emitting them as PIR.
> > 
> Fixed in r31225. I was going to say add a test, but 6 just started
> passing unexpectedly! :-)

Well, this is only "sorta fixed".  The problem with the approach being
used now is that we're limited to floating point formats that IMCC understands
(which is a little different from the formats that Perl 6 understands).

What really should happen here is that we take the same approach that
is being done for Ints -- namely, collect the characters that make up
the floating point literal into a Str or Perl6Str, numify the
string to obtain the correct floating point value, and pass that
value directly to PAST.

Unfortunately, at present Parrot doesn't seem to have a convenient way to
convert floating point values back into PIR literals without losing
lots of precision (RT #59006).  Thus a float value like 2.71828182845905
coming from the HLL source ends up being written as 2.71828 in the PIR
output, which is wrong by about 0.0182845905.  Thus the current
code simply passes the string directly from the source to PIR
(stripping underscores after the r31225 patch).  While this is a
reasonable workaround for now, it's not really the final answer we're
looking for.

I'm attaching RT #59006 as a dependency for this ticket -- when that
ticket is resolved, we can truly fix this one.

Thanks!

Pm

Re: Should $.foo attributes without "is rw" be writable from within the class

[Mark J. Reed]

I don't understand why this stuff is confusing; it's not new with Perl
6. There's a long tradition in O-O of distinguishing between the
externally visible accessor and the internal storage - Ruby self.foo
vs @foo, Java this.foo vs setFoo()/getFoo(), etc.  In fact the Ruby
case is directly analogous:

Perl 6 Ruby
has $.foo attr_reader :foo
has $.foo is rw attr_accessor :foo
$.foo

Re: throw oddities in pdd23

[Stephen Weeks]

Not long ago, Allison Randal proclaimed...
> Stephen Weeks wrote:
> >
> >This has now been committed to trunk.  I'm pretty sure that I updated
> >every exception handler in the tree.
> 
> Apologies if my comments on this thread and update to the exceptions PDD 
>  weren't clear. The resume continuation should continue to live within 
> the exception object, not be passed as a separate argument to the 
> handler. The change to remove the exception message string as a separate 
> parameter to the handler is correct, thanks for making that.
> 
> --
> (The current text of PDD23 is accurate:)
> Active exception handlers (if any) will be invoked with I as 
> the only parameter, and the return continuation stored within that 
> exception object.
> --
> 
> Please revert the branch merge or make another update.
This has been reverted.  I'll fix it and commit again sometime soon.

Re: Expected behavior of match?

[Patrick R. Michaud]

On Thu, Sep 18, 2008 at 05:17:07PM +0800, Chris Davaz wrote:
> The attached split.diff file is just for demonstration, not a patch submittal.
> 
> I made a method on Str called "match" that returns a List of all matches:
> 
> [...]
> loop:
>   $S0 = match.'text'()
>   if $S0 == '' goto done
>   retv.'push'($S0)
>   match.'next'()
>   goto loop
> 
> However, running the following code:
> say "ab1cd12ef123gh".match(/\d+/).perl;
> 
> We get:
> ["1", "12", "1", "2", "123", "12", "1", "23", "2", "3"]
> 
> As you can see match is returning what seems to be both greedy 
> *and* non-greedy matches (and everything in between). Is 
> this correct?

Yes.  The 'next' method on a Match object currently means that
we want to obtain the next possible match after any backtracking,
not the one that comes after the position of the previous one.  
We'll want this behavior to be able to support the :exhaustive modifier
(and PGE needs it in order to backtrack into subrules).

Try something like the following instead:

.sub 'match_global' :method :multi(_, 'Sub')
.param pmc regex
.local pmc retv, match

retv = 'list'()
$S0 = self
match = regex($S0)

  loop:
unless match goto done
push retv, match
match = regex(match)
goto loop

  done:
.return (retv)
.end


The line "match = regex(match)"  says to invoke the regex starting
at the .to position of the (previous) match object.

Pm

[perl #59006] stringifying Floats into PIR literals loses (a lot of) precision

[Patrick R. Michaud (via RT)]

# New Ticket Created by  Patrick R. Michaud 
# Please include the string:  [perl #59006]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=59006 >


When generating PIR output (e.g., from the compiler tools), we
often need to convert a Float value into an equivalent representation
for PIR.  Unfortunately, all of the mechanisms I've looked at for
doing this lose a lot of precision, which really isn't acceptable.

The prime candidate for this seems to be the C opcode,
which AFAICT is intended for this purpose.  However, it appears to
provide only about 7 digits of precision.

The approaches I've tried thus far are simple stringification,
the get_repr opcode, and variations on sprintf formats.  Here's
an example showing the difficulty:

$ cat x.pir
.sub 'main'
$N0 = exp 1.0
'as_pir'($N0)
.end

.sub 'as_pir'
.param pmc value

print "set_p_s  : "
$S0 = value
say $S0

print "get_repr : "
$S0 = get_repr value
say $S0

print "printf %g: "
$P0 = new 'ResizablePMCArray'
push $P0, value
$S0 = sprintf '%g', $P0
say $S0

.end

$ ./parrot x.pir
set_p_s  : 2.71828
get_repr : 2.718282
printf %g: 2.71828

By way of comparison, Perl 5 gives a far more reasonable result:

$ perl -e 'print exp(1),"\n"'
2.71828182845905

One approach might be to take whatever algorithm Perl 5 uses for
stringifying its floats (or something close to it), and adopt that
for get_repr and/or Float stringification.

The current situation blocks PCT's (and thus HLLs such as Rakudo)  
ability to generate reasonably accurate PIR involving floating point 
constants.  Phrased another way: to get reasonable floating point
semantics HLLs are currently having to restrict themselves to 
supporting floating point literal syntaxes that directly or easily 
translate to PIR output and don't rely on actually computing the 
float value.

Pm

Re: Should $.foo attributes without "is rw" be writable from within the class

[Aristotle Pagaltzis]

* Carl Mäsak <[EMAIL PROTECTED]> [2008-09-18 12:20]:
> 2. Start using $!foo consistently in methods, for both read and
>write accesses.

Unless, of course, you want the class-internal use of the
attribute to go through its accessor! Which you are likely
to want for public attributes, and much less likely for class-
private ones. So Perl 6 defaults the right thing here, it would
seem.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Should $.foo attributes without "is rw" be writable from within the class

[Aristotle Pagaltzis]

* Damian Conway <[EMAIL PROTECTED]> [2008-09-18 03:30]:
> When thinking about this, it's also important to remember that,
> in Perl 6, not everything with a sigil is automatically
> writeable.

That’s not even new to Perl 6.

$ perl -e's/foo/bar/ for "foo"'
Modification of a read-only value attempted at -e line 1.

-- 
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // 

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[Patrick R. Michaud]

On Thu, Sep 18, 2008 at 09:23:50AM +0200, Allison Randal wrote:
>>
>> What's the language-agnostic term for this, then?
>
> Well, 'gather' is basically a clever use of a coroutine, and 'take' is  
> basically a 'yield'. But, what's unique about the construct is that it  
> aggregates the results. So, 'gather' is an "aggregating coroutine" and  
> 'take' is an "aggregating yield". 

It's also a little unique that the "take/yield" can happen from called
subs deep within the coroutine, and doesn't have to occur within
the coroutine itself.

> To allow for a distinction in the  
> control exception types, call it 'CONTROL_YIELD_AGGREGATE'.
>
> "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy  
> as 'gather' and 'take', but they're more meaningful to a broader  
> audience, which may help the feature spread.

I'm rather hoping and expecting that "gather" and "take" become 
the meaningful names for this feature, much like "grep" started 
out as a Unix shell command but is now the language-agnostic term for
"extract things from a list matching a pattern".

Pm

[perl #45909] [TODO] Replace quadratic search with something linear in find_exception_handler()

[Christoph Otto via RT]

On Mon Oct 01 10:40:33 2007, pcoch wrote:
> In src/exceptions.c there is the todo comment: [TODO: replace
> quadratic search with something linear, hopefully without trashing
> abstraction layers


I can't find this comment any more, nor any occurrence of this ticket's
number.  I'll do some digging later to see where the comment went, but
it's likely that this ticket can be resolved or rejected.

Christoph

[perl #58828] Make calleable &-sigil parameters work in rakudo

[[EMAIL PROTECTED] via RT]

On Sat Sep 13 04:33:53 2008, masak wrote:
> In Rakudo r31066, this works...
> 
> $ ./perl6 -e 'sub a($b) { $b(5) }; a(&say)' # cool!
> 5
> 
> ...but not the following:
> 
>  rakudo: sub a(&b) { b(5) }; a(&say)
>  OUTPUT[Could not find non-existent sub b␤current instr.:
> 'a' pc 139
>   (EVAL_15:63)␤called from Sub '_block11' pc 27
> (EVAL_15:15)␤called from
>   Sub 'parrot;PCT::HLLCompiler;eval' pc 806
>   (src/PCT/HLLCompiler.pir:481)␤called from Sub
>   'parrot;PCT::HLLCompiler;evalfiles' pc 1078
>  ..(src/PCT/HLLCompiler.pir:610)␤called from Sub
>   'parrot;PCT::HLLCompiler;comma...
>  this is definitely not-yet-implemented-rakudo-feature
>  It should work according to S06
> 
> kthxbai.

OH HAI...you can haz fix in r31228. Plz I can haz spectests so we avoidz
regreshuns?

kthxbai,

Jonathan

[perl #58824] Inheriting from imported classes is broken in Rakudo

[[EMAIL PROTECTED] via RT]

On Sat Sep 13 03:41:27 2008, masak wrote:
> Rakudo r31066 is experiencing problems with classes defined in "use"d
> modules.
> 
> $ perl6 -e 'class A {}; class B is A {}' # this works
> $ cat A.pm # but... put the class A in a file...
> class A {}
> $ ./perl6 -e 'use A; class B is A {}' # ...and it stops working
> Attempt to inherit from non-existent parent class
> [...]
> 
Ah, I fixed a dupe of this ticket earlier on today - use wasn't being
done at compile time, but rather at runtime. Just checked and this now
works, so resolving ticket.

Thanks,

Jonathan

New Parrot mailing list

[Allison Randal]

The new Parrot mailing list (replacing perl6-internals/parrot-porters) 
is <[EMAIL PROTECTED]>. If you were subscribed to the old 
list, you're now subscribed to the new list. If you were a digest 
subscriber to the old list, you're now a digest subscriber to the new list.


More information about the list and public archives are available at:

http://lists.parrot.org/mailman/listinfo/parrot-dev


A Google group for the list has been created at:

http://groups.google.com/group/parrot-dev


We'll likely end up with messages scattered between both lists for a 
little while, but the perl6-internals/parrot-porters addresses are 
deprecated and will be disabled after a sensible deprecation cycle (and 
after the automatic RT posts have been shifted to parrot-dev).


The new mailing list will not automatically update tickets in the RT 
queue, for that CC <[EMAIL PROTECTED]> on the message.


Allison

[svn:parrot-pdd] r31223 - in trunk: compilers/bcg/t compilers/pct/src/PAST compilers/pct/src/PCT docs docs/pdds languages/APL/src/parser languages/WMLScript languages/WMLScript/src languages/dotnet/bu

[tene]

Author: tene
Date: Thu Sep 18 01:47:46 2008
New Revision: 31223

Modified:
   trunk/docs/pdds/pdd19_pir.pod
   trunk/docs/pdds/pdd23_exceptions.pod

Changes in other areas also in this revision:
Modified:
   trunk/compilers/bcg/t/BCG.t
   trunk/compilers/pct/src/PAST/Compiler.pir
   trunk/compilers/pct/src/PCT/HLLCompiler.pir
   trunk/docs/compiler_faq.pod
   trunk/languages/APL/src/parser/actions.pm
   trunk/languages/WMLScript/src/wmlsstdlibs.pir
   trunk/languages/WMLScript/wmls2pbc.pir
   trunk/languages/WMLScript/wmls2pir.pir
   trunk/languages/WMLScript/wmlsd.pir
   trunk/languages/WMLScript/wmlsi.pir
   trunk/languages/dotnet/build/translator.pl
   trunk/languages/dotnet/src/translator.pir
   trunk/languages/ecmascript/src/parser/actions.pm
   trunk/languages/forth/forth.pir
   trunk/languages/forth/test.pir
   trunk/languages/lua/luac2pir.pir
   trunk/languages/lua/luad.pir
   trunk/languages/lua/src/lib/bc.pir
   trunk/languages/lua/src/lib/glut.pir
   trunk/languages/lua/src/lib/lfs.pir
   trunk/languages/lua/src/lib/luaaux.pir
   trunk/languages/lua/src/lib/luabasic.pir
   trunk/languages/lua/src/lib/luacoroutine.pir
   trunk/languages/lua/src/lib/luadebug.pir
   trunk/languages/lua/src/lib/luaos.pir
   trunk/languages/perl6/src/builtins/control.pir
   trunk/languages/perl6/src/parser/actions.pm
   trunk/languages/pheme/pheme.pir
   trunk/languages/squaak/src/parser/actions.pm
   trunk/languages/tcl/runtime/builtin/dict.pir
   trunk/languages/tcl/runtime/builtin/info.pir
   trunk/languages/tcl/runtime/builtin/inline.pir
   trunk/languages/tcl/runtime/conversions.pir
   trunk/languages/tcl/src/macros.pir
   trunk/languages/tcl/t/internals/select_option.t
   trunk/languages/tcl/t/internals/select_switches.t
   trunk/src/exceptions.c
   trunk/src/ops/core.ops
   trunk/src/pmc/exception.pmc
   trunk/t/compilers/pge/p5regex/p5rx.t
   trunk/t/compilers/pge/perl6regex/01-regex.t
   trunk/t/library/pg.t
   trunk/t/op/calling.t
   trunk/t/op/exceptions.t
   trunk/t/op/sprintf.t
   trunk/t/pmc/bigint.t
   trunk/t/pmc/complex.t
   trunk/t/pmc/coroutine.t
   trunk/t/pmc/exception.t
   trunk/t/pmc/float.t
   trunk/t/pmc/namespace.t
   trunk/t/pmc/resizablestringarray.t

Log:
Revert my previous exceptions commit.  It was wrong.


Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Thu Sep 18 01:47:46 2008
@@ -617,15 +617,18 @@
 Using the C op you can install an exception handler. If an exception
 is thrown, Parrot will execute the installed exception handler. In order to
 retrieve the thrown exception, use the C<.get_results> directive. This
-directive always takes 2 arguments: an exception object and a return
-continuation.
+directive always takes 2 arguments: an exception object and a message string.
+
+{{ NOTE: Wouldn't it be more useful to make this flexible, or at least only
+the exception object? The message can be retrieved from the exception object.
+See RT #57436 }}
 
push_eh handler
...
  handler:
.local pmc exception
-   .local pmc continuation
-   .get_results (exception, continuation)
+   .local string message
+   .get_results (exception, message)
...
 
 This is syntactic sugar for the C op, but any flags set on the
@@ -633,15 +636,6 @@
 The C<.get_results> directive must be the first instruction of the exception
 handler; only declarations (.lex, .local) may come first.
 
-To resume execution after handling the exception, just invoke the continuation
-parameter.
-
-   ...
-   .get_results(exception,continuation
-   ...
-   continuation()
-   ...
-
 =head2 Syntactic Sugar
 
 Any PASM opcode is a valid PIR instruction. In addition, PIR defines some

Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podThu Sep 18 01:47:46 2008
@@ -66,17 +66,18 @@
 
 =item B [ , I ]>
 
-Throw the given I PMC to the active exception handlers.
-If a I is not passed in, throw will take a new one at
-the next opcode.  Active exception handlers (if any) will be
-invoked with I and the given continuation as parameters.
+Throw an exception consisting of the given I PMC, after taking a
+continuation at the next opcode. When a I is passed in, it will
+use that instead of generating a new continuation. Active exception handlers
+(if any) will be invoked with I as the only parameter, and the
+return continuation stored within that exception object.
 
 PMCs other than Parrot's Exception PMC may also be thrown, but they must
 support the interface of an Exception PMC. An HLL may implement throwing any
 arbitrary type of PMC, by storing that PMC as the payload of an Exception PMC.
 
 Exception handlers can resume execution immediately after the C opcode
-by invoking the resume conti

[perl #58924] [BUG] my %a; %a = 't'; for keys %a { .say } misbehaving

[[EMAIL PROTECTED] via RT]

On Tue Sep 16 08:56:29 2008, cognominal wrote:
> It prints "0\n" instead of the expected "i\n"
> 
Fixed this in 31227, and values, and also cleaned up kv. They are now
multis that we use !EXPORT on (kv had been written specially rather than
just exporting the kv method on Mapping - just deleted that and added it
to export list).

Fixing these passes us another 8 TODO'd spectests. w00t.

Thanks,

Jonathan

[perl #58936] [TODO] promote 'use' to happen at compile time

[[EMAIL PROTECTED] via RT]

On Tue Sep 16 13:04:11 2008, [EMAIL PROTECTED] wrote:
> ...
> But move class Dog { ... } into Dog.pm and import it with
> 'use Dog;' and Rakudo is like 'Attempt to inherit from
> non-existent parent class'.
> 
This bug is like fixed.

Well, kinda. Your example now runs. However, modules using modules then
causes some fun (though I'm not convinced this change has made the
situation worse), and this won't play so nicely with pre-compiled
modules. Those'll want tickets of their own, though, so resolving this
ticket since use has been promoted to happen at runtime now.

Thanks,

Jonathan

[perl #58998] [TODO] remove underscores from numbers to make imcc happy

[[EMAIL PROTECTED] via RT]

On Thu Sep 18 00:49:59 2008, [EMAIL PROTECTED] wrote:
> r31220:
> > say 23_433
> 23433
> > say 23_433.4_4
> error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
> in file 'EVAL_13' line 12
> 23
> 
> Obviously the underscores in the fractional part of the number needs to
> be stripped by rakudo before emitting them as PIR.
> 
Fixed in r31225. I was going to say add a test, but 6 just started
passing unexpectedly! :-)

Thanks,

Jonathan

Re: Should $.foo attributes without "is rw" be writable from within the class

[Carl Mäsak]

I really like all the replies I got to this; thank you Moritz,
Jonathan, TSa, Larry, John and Damian.

>From the feedback I received, I will now do the following:

1. Remove "is rw" from all attributes that aren't supposed to be
writable from outside the class.

2. Start using $!foo consistently in methods, for both read and write accesses.

It remains to be seen whether the greater understanding you have given
me about the inner workings of Perl 6 classes will make this system
bearable. :) I hope it will.

// Carl

S05 and S29 may conflict on behavior of $string.match(/pat/)

[Chris Davaz]

I'm trying to pin down what $string.match(/pat/) should be returning.

>From S05:

Under "Return values from match objects"
"A match always returns a Match object..."

>From S29:

Under the definition of Str.comb

Saying

$string.comb(/pat/, $n)

is equivalent to

$string.match(rx:global:x(0..$n):c/pat/)

[ ...and later... ]

"If there are captures in the pattern, a list of Match objects (one
per match) is returned instead of strings."

Which implies that $string.match(/pat/) should indeed return a List of
Str and $string.match(/pat_with_groups/) should return a List of
Match.

I expected the S29 definition when first approaching $string.match I
feel it is more intuitive than what happens with S05. Could someone
clarify what the behavior should be?

Best Regards,
-Chris Davaz

Re: Parrot 0.7.1 "Manu Aloha" released

[Reini Urban]

2008/9/17 Patrick R. Michaud <[EMAIL PROTECTED]>:
> On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
>> http://www.parrotcode.org/release/devel still points to 0.7.0
>
> I sent the appropriate patch to the webmaster, but it hasn't
> been applied yet (and I lack a commit bit for the parrotcode.org site).
> Once that's applied, the url should be fixed.

FYI:
I thought the best generic method to get the latest release URI should be
SRC_URI=$(lwp-request -m HEAD -x -e
"http://www.parrotcode.org/release/devel"; 2>&1 | \
grep "/authors/id" | tail -n1 | perl -ane 'print $F[2]')

The authors id changes in the uri below with every release:
  http://search.cpan.org/CPAN/authors/id/P/M/PMIC/parrot-${PV}.tar.gz
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Expected behavior of match?

[Chris Davaz]

The attached split.diff file is just for demonstration, not a patch
submittal.

I made a method on Str called "match" that returns a List of all matches:

# returns all matches on a regex
.sub 'match' :method :multi(_, 'Sub')
.param pmc regex
.local pmc match
.local pmc tmpstr
.local pmc retv

retv = new 'List'
match = regex.'ACCEPTS'(self)

loop:
  $S0 = match.'text'()
  if $S0 == '' goto done
  retv.'push'($S0)
  match.'next'()
  goto loop

done:
  .return(retv)
.end

However, running the following code:
say "ab1cd12ef123gh".match(/\d+/).perl;

We get:
["1", "12", "1", "2", "123", "12", "1", "23", "2", "3"]

As you can see match is returning what seems to be both greedy *and*
non-greedy matches (and everything in between). Is this correct?
Index: src/classes/Str.pir
===
--- src/classes/Str.pir	(revision 31220)
+++ src/classes/Str.pir	(working copy)
@@ -76,6 +76,78 @@
 .return(retv)
 .end
 
+# returns all matches on a regex
+.sub 'match' :method :multi(_, 'Sub')
+.param pmc regex
+.local pmc match
+.local pmc tmpstr
+.local pmc retv
+
+retv = new 'List'
+match = regex.'ACCEPTS'(self)
+
+loop:
+  $S0 = match.'text'()
+  if $S0 == '' goto done
+  retv.'push'($S0)
+  match.'next'()
+  goto loop
+
+done:
+  .return(retv)
+.end
+
+# split a string on a regex
+.sub 'split' :method :multi(_, 'Sub')
+.param pmc regex 
+.local pmc match
+.local pmc tmpstr
+.local pmc retv
+.local int start_pos
+.local int end_pos
+
+retv = new 'List'
+
+match = regex.'ACCEPTS'(self)
+unless match goto done
+
+start_pos = 0
+end_pos = match.'from'()
+
+  loop:
+print "start_pos = "
+print start_pos
+print "; end_pos = "
+say end_pos
+$S7 = match.'text'()
+say $S7
+
+tmpstr = new 'Perl6Str'
+$S0 = substr self, start_pos, end_pos
+tmpstr = $S0
+retv.'push'(tmpstr)
+
+start_pos = match.'to'()
+
+match.'next'()
+
+end_pos = match.'from'()
+end_pos -= start_pos
+
+$S1 = match.'text'()
+if $S1 == '' goto last
+goto loop
+
+  last:
+tmpstr = new 'Perl6Str'
+$S0 = substr self, start_pos, end_pos
+tmpstr = $S0
+retv.'push'(tmpstr)
+
+  done:
+.return(retv)
+.end
+
 .sub lc :method
 .local string tmps
 .local pmc retv


split.p6
Description: Binary data

[perl #58998] [TODO] remove underscores from numbers to make imcc happy

[via RT]

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


r31220:
> say 23_433
23433
> say 23_433.4_4
error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' ('_433')
in file 'EVAL_13' line 12
23

Obviously the underscores in the fractional part of the number needs to
be stripped by rakudo before emitting them as PIR.

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

[perl #58988] [RFC] Parrot_get_runtime_prefix function

[via RT]

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


The Parrot_get_runtime_prefix in src/library.c return a char *,
forcing the places that currently uses it to be more complicated than
desired for no real gain. I added and used a STRING * variant named
Parrot_get_runtime_path (that name makes more sense to me) in r31216

The question is: must we retain the old variant, kill it, deprecate
it, use his name for the new version, or revert the change and stay
with the char * way?

-- 
Salu2

[svn:parrot-pdd] r31218 - in trunk: compilers/bcg/t compilers/pct/src/PAST compilers/pct/src/PCT docs/pdds languages/APL/src/parser languages/WMLScript languages/WMLScript/src languages/dotnet/build l

[tene]

Author: tene
Date: Wed Sep 17 20:34:19 2008
New Revision: 31218

Modified:
   trunk/docs/pdds/pdd19_pir.pod
   trunk/docs/pdds/pdd23_exceptions.pod

Changes in other areas also in this revision:
Modified:
   trunk/compilers/bcg/t/BCG.t
   trunk/compilers/pct/src/PAST/Compiler.pir
   trunk/compilers/pct/src/PCT/HLLCompiler.pir
   trunk/languages/APL/src/parser/actions.pm
   trunk/languages/WMLScript/src/wmlsstdlibs.pir
   trunk/languages/WMLScript/wmls2pbc.pir
   trunk/languages/WMLScript/wmls2pir.pir
   trunk/languages/WMLScript/wmlsd.pir
   trunk/languages/WMLScript/wmlsi.pir
   trunk/languages/dotnet/build/translator.pl
   trunk/languages/dotnet/src/translator.pir
   trunk/languages/ecmascript/src/parser/actions.pm
   trunk/languages/forth/forth.pir
   trunk/languages/forth/test.pir
   trunk/languages/lua/luac2pir.pir
   trunk/languages/lua/luad.pir
   trunk/languages/lua/src/lib/bc.pir
   trunk/languages/lua/src/lib/glut.pir
   trunk/languages/lua/src/lib/lfs.pir
   trunk/languages/lua/src/lib/luaaux.pir
   trunk/languages/lua/src/lib/luabasic.pir
   trunk/languages/lua/src/lib/luacoroutine.pir
   trunk/languages/lua/src/lib/luadebug.pir
   trunk/languages/lua/src/lib/luaos.pir
   trunk/languages/perl6/src/builtins/control.pir
   trunk/languages/perl6/src/parser/actions.pm
   trunk/languages/pheme/pheme.pir
   trunk/languages/squaak/src/parser/actions.pm
   trunk/languages/tcl/runtime/builtin/dict.pir
   trunk/languages/tcl/runtime/builtin/info.pir
   trunk/languages/tcl/runtime/builtin/inline.pir
   trunk/languages/tcl/runtime/conversions.pir
   trunk/languages/tcl/src/macros.pir
   trunk/languages/tcl/t/internals/select_option.t
   trunk/languages/tcl/t/internals/select_switches.t
   trunk/src/exceptions.c
   trunk/src/ops/core.ops
   trunk/src/pmc/exception.pmc
   trunk/t/compilers/pge/p5regex/p5rx.t
   trunk/t/compilers/pge/perl6regex/01-regex.t
   trunk/t/library/pg.t
   trunk/t/op/calling.t
   trunk/t/op/exceptions.t
   trunk/t/op/sprintf.t
   trunk/t/pmc/bigint.t
   trunk/t/pmc/complex.t
   trunk/t/pmc/coroutine.t
   trunk/t/pmc/exception.t
   trunk/t/pmc/float.t
   trunk/t/pmc/namespace.t
   trunk/t/pmc/resizablestringarray.t

Log:
Merge exceptionmagic branch into trunk.


Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Wed Sep 17 20:34:19 2008
@@ -617,18 +617,15 @@
 Using the C op you can install an exception handler. If an exception
 is thrown, Parrot will execute the installed exception handler. In order to
 retrieve the thrown exception, use the C<.get_results> directive. This
-directive always takes 2 arguments: an exception object and a message string.
-
-{{ NOTE: Wouldn't it be more useful to make this flexible, or at least only
-the exception object? The message can be retrieved from the exception object.
-See RT #57436 }}
+directive always takes 2 arguments: an exception object and a return
+continuation.
 
push_eh handler
...
  handler:
.local pmc exception
-   .local string message
-   .get_results (exception, message)
+   .local pmc continuation
+   .get_results (exception, continuation)
...
 
 This is syntactic sugar for the C op, but any flags set on the
@@ -636,6 +633,15 @@
 The C<.get_results> directive must be the first instruction of the exception
 handler; only declarations (.lex, .local) may come first.
 
+To resume execution after handling the exception, just invoke the continuation
+parameter.
+
+   ...
+   .get_results(exception,continuation
+   ...
+   continuation()
+   ...
+
 =head2 Syntactic Sugar
 
 Any PASM opcode is a valid PIR instruction. In addition, PIR defines some

Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podWed Sep 17 20:34:19 2008
@@ -66,18 +66,17 @@
 
 =item B [ , I ]>
 
-Throw an exception consisting of the given I PMC, after taking a
-continuation at the next opcode. When a I is passed in, it will
-use that instead of generating a new continuation. Active exception handlers
-(if any) will be invoked with I as the only parameter, and the
-return continuation stored within that exception object.
+Throw the given I PMC to the active exception handlers.
+If a I is not passed in, throw will take a new one at
+the next opcode.  Active exception handlers (if any) will be
+invoked with I and the given continuation as parameters.
 
 PMCs other than Parrot's Exception PMC may also be thrown, but they must
 support the interface of an Exception PMC. An HLL may implement throwing any
 arbitrary type of PMC, by storing that PMC as the payload of an Exception PMC.
 
 Exception handlers can resume execution immediately after the C opcode
-by invoking the resume continuation which is stored in the exception obj

Re: throw oddities in pdd23

[Allison Randal]

Stephen Weeks wrote:


This has now been committed to trunk.  I'm pretty sure that I updated
every exception handler in the tree.


Apologies if my comments on this thread and update to the exceptions PDD 
 weren't clear. The resume continuation should continue to live within 
the exception object, not be passed as a separate argument to the 
handler. The change to remove the exception message string as a separate 
parameter to the handler is correct, thanks for making that.


--
(The current text of PDD23 is accurate:)
Active exception handlers (if any) will be invoked with I as 
the only parameter, and the return continuation stored within that 
exception object.

--

Please revert the branch merge or make another update.

Thanks!
Allison

[perl #59000] [BUG] r31218 introduced a segfault in S04-statements/gather.t

[via RT]

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


starting from r31218 this test segfaults (i386 32 bit linux):

$ TEST_JOBS=1 make t/spec/S04-statements/gather.t
t/spec/S04-statements/gather.rakudo
1..12
not ok 1 - not yet gathered # TODO lazy gather/takr
ok 2 - 5 elements gathered
ok 3 - gather code executed
ok 4 - first elem taken
ok 5 - # SKIP * not implemented
ok 6 - nested gather works (two levels)
ok 7 - nested gather works (three levels)
ok 8 - take on lists and multiple takes work
 Failed 4/12 subtests
(less 1 skipped subtest: 7 okay)

Test Summary Report
---
t/spec/S04-statements/gather.rakudo (Wstat: 11 Tests: 8 Failed: 0)
  Parse errors: Bad plan.  You planned 12 tests but ran 8.
Files=1, Tests=8,  2 wallclock secs ( 0.01 usr  0.00 sys +  1.67 cusr
0.04 csys =  1.72 CPU)
Result: FAIL

$ ../../parrot -G perl6.pbc  t/spec/S04-statements/gather.rakudo
1..12
not ok 1 - not yet gathered# TODO lazy gather/takr
ok 2 - 5 elements gathered
ok 3 - gather code executed
ok 4 - first elem taken
ok 5 - # SKIP * not implemented
ok 6 - nested gather works (two levels)
ok 7 - nested gather works (three levels)
ok 8 - take on lists and multiple takes work
Segmentation fault

[perl #58866] calling a PIR sub with 206 params segfaults parrot

[Christoph Otto via RT]

On Wed Sep 17 08:31:26 2008, particle wrote:
> On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT
> <[EMAIL PROTECTED]> wrote:
> > On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote:
> >> On Tuesday 16 September 2008 14:47:58 NotFound wrote:
> >>
> >> > > It certainly shouldn't segfault. But, the question is: why does it
> >> > > segfault at 206 parameters? Throwing an exception to avoid an
> >> error we
> >> > > don't understand isn't good for the long-term health of the VM.
> >> >
> >> > The problem is located inside compilers/imcc/pcc.c:pcc_get_args
> >> function.
> >> >
> >> > It has the comment /* XXX check avail len */ just at the point where
> >> > the segfault happens. char buf[1024] is the variable overrunned.
> >>
> >> That sounds like a bog-standard static variable overflow, where each
> >> parameter
> >> requires five bytes of storage.  If that's a good rule of thumb, we
> >> could
> >> malloc/free that buffer instead, and then beat anyone who uses more
> >> than a
> >> dozen parameters.
> >>
> >> -- c
> >>
> >
> >
> > Looking at the code, it's 5n+1.  r31200 changes the static buffer to a
> > dynamic one of the correct size.  The original PIR code now runs without
> > segfaulting, as does a version with 20,000 int params.  make test also
> > passes, so nothing new appears to be broken.
> >
> > With the assumption that the said beatings will be a manual process, I'm
> > marking this resolved.
> >
> 
> you didn't mention it, but i sincerely hope you committed a test with
> 20,000 params that proves this and makes sure we don't regress in a
> future revision. parrot needs much more stress testing like this, and
> it would be a shame to miss this opportunity.
> ~jerry
> 

I didn't think of it until after I went to bed, but I added one with
1000 params in r31208 the next morning.  The 20,000 param version took
more than a second to run and I didn't see any reason to slow the tests
down more than necessary.

Re: throw oddities in pdd23

[Stephen Weeks]

Not long ago, Stephen Weeks proclaimed...
> Not long ago, Patrick R. Michaud proclaimed...
> > Personally I like the idea that "any PMC can be thrown as an
> > exception", which would seem to argue against forcing resume
> > continuations into the thrown PMC (which might not have a slot
> > for them).  So, rather than saying that anything thrown as an 
> > exception contains its resume continuation, perhaps we should 
> > say that all handlers are invoked with the exception and resume 
> > continuation as arguments, and the single-argument throw simply 
> > takes a continuation at the next instruction to pass to the
> > handler(s).  
> > 
> > Pm
> 
> This proposal has been implemented in the exceptionmagic branch.
> Looks like all tests are passing there without problem, although I'm
> not certain about a couple of the languages.
> 
> Can I get some confirmation from someone else on the desirability of
> this proposal?

This has now been committed to trunk.  I'm pretty sure that I updated
every exception handler in the tree.

[perl #41291] [RFC] Can't use null PMC with :multi sub

[Christoph Otto via RT]

On Thu Jan 18 14:14:30 2007, mdiep wrote:
> On Thu Jan 18 13:52:33 2007, leo wrote:
> > While that was never actually specced, I do consider a NULL PMC as
> > something
> > like a null pointer in C. Any access (except testing for NULL-ness)
> to
> > it is
> > an error. Above example tests, that some usage of a NULL PMC fails.
> >
> > It's of course debatable, which usage of NULL should be allowed,
> e.g.
> > above
> > one. An explicit test in PMC->type conversion for PMCNULL in the MMD
> > code is
> > very likely all to make above code running (mmd.c:167,168).
> 
> I based the bug report on the behavior of normal subs:
> 
> .sub main :main
> null $P0
> foo($P0) # this *does* print "foo\n"
> .end
> .sub foo
> say "foo"
> .end
> 
> I don't know that I particularly need to be able to pass null PMCs to
> a MultiSub, but I at least
> demand a better error message. :-) I think either way will be trivial
> to write, but it probably
> needs some input from the architect.
> 
> --
> Matt Diephouse
> 

The above code prints "Any" in the mmd branch.  Unless that's an
unwanted behavior, it looks like this ticket can be resolved once the
mmd branch is merged.

[perl #54110] [BUG] segfault in infix/n_infix with string arguments

[Christoph Otto via RT]

On Tue Sep 09 15:06:38 2008, [EMAIL PROTECTED] wrote:
> Patrick R. Michaud wrote:
> > 
> > Just for clarification:  IIUC, the n_* opcodes and their semantics
> > aren't really "going away" -- they're simply being renamed to not 
> > have the leading "n_" prefix.  It's the existing "add", "sub", 
> > "mul", "div", etc.  opcodes that are being eliminated.
> 
> Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for 
> the result on all the builtin PMCs. But, HLL/application developers will 
> have the option of writing their own PMCs that reuse the destination PMC 
> instead of a creating a new one.
> 
> [...]
> > This would seem to indicate that the string variants of the
> > various math opcodes are also going away (and that's okay with me).
> > 
> > So, if we can just get an official ruling that the add_p_p_s,
> > sub_p_p_s, etc. opcodes are going away, then we can close this
> > ticket as moot. 
> 
> Yes, these string variants only existed because of the unintelligent way 
> the infix/n_infix opcodes blindly redispatched. In the branch, where the 
> math opcodes are real opcodes, there are no string variants and we're 
> not adding them.
> 
> So, ticket can be reclassified as irrelevant.
> 
> Allison
> 

In that case it's rejected.

[perl #58020] Fix problem with using Str as a type constraint or in MMD

[Moritz Lenz via RT]

On Sat Aug 16 08:29:16 2008, [EMAIL PROTECTED] wrote:
> - File an RT ticket for this?

All Str related tests haven been un-fudged in
t/spec/S06-multi/type-based.t and are now passing (after jonathan++
switched to the new rakudo mmd), and I can't observe any oddities with
type constraints either.

So resolving this ticket, if there are still troubles please re-open and
provide a test case.

Moritz

[perl #58982] Bug -- make per6 unexpected dot

[Kamil Ku�aga]

# New Ticket Created by  "Kamil Kułaga" 
# Please include the string:  [perl #58982]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58982 >


$ make perl6
make -C compilers/pct
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/pct'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/pct'
make -C compilers/pge
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/pge'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/pge'
make -C compilers/tge
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/tge'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/tge'
make -C compilers/nqp
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/nqp'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/nqp'
make -C compilers/json
make[1]: Wejście do katalogu `/usr/local/src/parrot/compilers/json'
make[1]: Nie ma nic do zrobienia w `all'.
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/compilers/json'
make -C languages/perl6 perl6
make[1]: Wejście do katalogu `/usr/local/src/parrot/languages/perl6'
../../parrot  -o perl6.pbc perl6.pir
error:imcc:syntax error, unexpected DOT ('.')
in file 'src/gen_builtins.pir' line 7787
included from 'perl6.pir' line 1
make[1]: *** [perl6.pbc] Błąd 1
make[1]: Opuszczenie katalogu `/usr/local/src/parrot/languages/perl6'
make: *** [perl6] Błąd 2



-- 
Pozdrawiam

Re: [perl #58970] Initial implementation of Str.split(Regex)

[Moritz Lenz]

Chris Davaz wrote:
> hmm I see I'll work it out ;-) Thanks

I just found out that the segfault is not introduced by your patch, one
less worry for you ;-)

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [perl #58970] Initial implementation of Str.split(Regex)

[Chris Davaz]

hmm I see I'll work it out ;-) Thanks

On Thu, Sep 18, 2008 at 3:33 PM, Moritz Lenz <[EMAIL PROTECTED]>wrote:
>
>> Chris Davaz wrote:
>> > Ok, here it is without the change to "split on a string", and the test
>> > passes.
>>
>> Yes, but on my machine now t/spec/S04-statements/gather.t produces a
>> segmentation fault. I'll have to investigate if that is related to your
>> patch or not.
>>
>> Also split behaves a bit strangely here:
>>
>>  > say 'ab23d4f5'.split(/\d+/).perl
>>  ["ab", "", "", "d", "f", ""]
>>  > say 'ab23d4f5'.split(/\d/).perl
>>  ["ab", "", "d", "f", ""]
>>
>> (There are a few other oddities like the behaviour with a zero-width
>> match, but that's only a minor issue).
>>
>> > Please apply this one and in the meantime I will see how we can
>> > get the method signature right for split on a strong + not break
>> reverse.
>>
>> --
>> Moritz Lenz
>> http://moritz.faui2k3.org/ |  http://perl-6.de/
>>
>
>

Re: [perl #58970] Initial implementation of Str.split(Regex)

[Moritz Lenz]

Chris Davaz wrote:
> Ok, here it is without the change to "split on a string", and the test
> passes.

Yes, but on my machine now t/spec/S04-statements/gather.t produces a
segmentation fault. I'll have to investigate if that is related to your
patch or not.

Also split behaves a bit strangely here:

 > say 'ab23d4f5'.split(/\d+/).perl
 ["ab", "", "", "d", "f", ""]
 > say 'ab23d4f5'.split(/\d/).perl
 ["ab", "", "d", "f", ""]

(There are a few other oddities like the behaviour with a zero-width
match, but that's only a minor issue).

> Please apply this one and in the meantime I will see how we can
> get the method signature right for split on a strong + not break reverse.

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t

[Allison Randal]

Patrick R. Michaud wrote:


What's the language-agnostic term for this, then?


Well, 'gather' is basically a clever use of a coroutine, and 'take' is 
basically a 'yield'. But, what's unique about the construct is that it 
aggregates the results. So, 'gather' is an "aggregating coroutine" and 
'take' is an "aggregating yield". To allow for a distinction in the 
control exception types, call it 'CONTROL_YIELD_AGGREGATE'.


"Aggregating coroutine" and "aggregating yield" aren't nearly as zippy 
as 'gather' and 'take', but they're more meaningful to a broader 
audience, which may help the feature spread.


Allison