trying to use a role within a role

[Richard Hainsworth]

Could someone please tell me what is wrong with the following?

role win_text {
 has $.win_mytxt1 is rw;
 has $.win_mytxt2 is rw;
};

role mywindow {
 has $.border is rw;
 has $.colour is rw;
 does win_text;
};

my $w = new mywindow;

$w.border = 2;
$w.colour = 'red';
say $w.border;
say $w.colour;

$w.win_mytxt1 = 'quick red fox';
$w.win_mytxt2 = ' jumped over the lazy dog';
say $w.win_mytxt1 ~ $.win_mytxt2;

Running in a terminal yields:

$ pugs ./test.p6
2
red
*** No compatible subroutine found: "&win_mytxt1"
   at ./test.p6 line 19, column 1-32
$

Hence defining attributes in a role and accessing them works as defined 
in Synopsis 12. (If I understand the synopsis correctly, when I write 
'my $w = new mywindow' I am autogenerating a class from a role.) 
Otherwise I would not get the '2' and 'red' printed out.


But I could not find any mention that an attribute in a role called by a 
role would have to be accessed differently.


Regards,
Richard

Re: [perl #40438] Extending a dynpmc with a PIR method fails

[Kevin Tew]

The attached patch is my first step at locating bug #40438.

It adds pdump -d functionality for keys.


Leopold Toetsch via RT wrote:

Thanks, I've applied a modified version of the patch, showing that it's
a namespace issue caused by the .HLL line. Using .loadlib works fine and
as expected.

leo
  


=== include/parrot/packfile.h
==
--- include/parrot/packfile.h   (revision 133)
+++ include/parrot/packfile.h   (local)
@@ -375,7 +375,7 @@
 
 PARROT_API size_t PackFile_Constant_pack_size(Interp *, struct 
PackFile_Constant * self);
 
-PARROT_API opcode_t * PackFile_Constant_pack(Interp *, struct 
PackFile_Constant *, opcode_t *);
+PARROT_API opcode_t * PackFile_Constant_pack(Interp *, struct 
PackFile_ConstTable *ct, struct PackFile_Constant *, opcode_t *);
 
 PARROT_API void PackFile_Constant_destroy(Interp *, struct PackFile_Constant * 
self);
 
@@ -388,6 +388,9 @@
 PARROT_API opcode_t * PackFile_Constant_unpack_pmc(Interp *interpreter,
 struct PackFile_ConstTable *, struct PackFile_Constant *, opcode_t *);
 
+PARROT_API int PackFile_find_in_const(Interp *interpreter, struct 
PackFile_ConstTable *ct,
+PMC *key, int type);
+
 /*
  * pf_items low level Parrot items fetch routines
  */
=== src/packdump.c
==
--- src/packdump.c  (revision 133)
+++ src/packdump.c  (local)
@@ -30,7 +30,7 @@
 
 void PackFile_ConstTable_dump(Interp *,
  struct PackFile_ConstTable *);
-static void PackFile_Constant_dump(Interp *,
+static void PackFile_Constant_dump(Interp *, struct PackFile_ConstTable *ct,
struct PackFile_Constant *);
 void PackFile_Fixup_dump(Interp *,
  struct PackFile_FixupTable *ft);
@@ -55,14 +55,14 @@
 
 for (i = 0; i < self->const_count; i++) {
 PIO_printf(interpreter, "# %ld:\n", (long)i);
-PackFile_Constant_dump(interpreter, self->constants[i]);
+PackFile_Constant_dump(interpreter, self, self->constants[i]);
 }
 }
 
 /*
 
 =item C
 
 Dumps the constant C.
@@ -72,9 +72,15 @@
 */
 
 void
-PackFile_Constant_dump(Interp *interpreter,
+PackFile_Constant_dump(Interp *interpreter, struct PackFile_ConstTable *ct,
struct PackFile_Constant *self)
 {
+struct PMC *key;
+size_t i;
+size_t ct_index;
+opcode_t slice_bits;
+struct PackFile_Constant *detail;
+
 switch (self->type) {
 
 case PFC_NUMBER:
@@ -97,9 +103,84 @@
 break;
 
 case PFC_KEY:
-PIO_printf(interpreter, "[ 'PFC_KEY', {\n");
-PIO_printf(interpreter, "??? TODO \n");
-PIO_printf(interpreter, "} ],\n");
+PIO_printf(interpreter, "[ 'PFC_KEY");
+for (i = 0, key = self->u.key; key; key = PMC_data(key), i++)
+;
+/* number of key components */
+PIO_printf(interpreter, " %ld items\n", i);
+/* and now type / value per component */
+for (key = self->u.key; key; key = PMC_data(key)) {
+PIO_printf(interpreter, "   {\n");
+opcode_t type = PObj_get_FLAGS(key);
+slice_bits = 0;
+if ((type & (KEY_start_slice_FLAG|KEY_inf_slice_FLAG)) ==
+(KEY_start_slice_FLAG|KEY_inf_slice_FLAG))
+PIO_printf(interpreter, "SLICE_BITS  => 
PF_VT_END_INF\n");
+if ((type & (KEY_end_slice_FLAG|KEY_inf_slice_FLAG)) ==
+(KEY_end_slice_FLAG|KEY_inf_slice_FLAG))
+slice_bits |= PF_VT_START_ZERO;
+PIO_printf(interpreter, "SLICE_BITS  => 
PF_VT_START_ZERO\n");
+if (type & KEY_start_slice_FLAG)
+slice_bits |= PF_VT_START_SLICE;
+PIO_printf(interpreter, "SLICE_BITS  => 
PF_VT_START_SLICE\n");
+if (type & KEY_end_slice_FLAG)
+slice_bits |= PF_VT_END_SLICE;
+PIO_printf(interpreter, "SLICE_BITS  => 
PF_VT_END_SLICE\n");
+
+type &= KEY_type_FLAGS;
+PIO_printf(interpreter, "FLAGS   => 0x%04lx,\n", 
(long)PObj_get_FLAGS(key));
+switch (type) {
+case KEY_integer_FLAG:
+PIO_printf(interpreter, "TYPE=> 
INTEGER\n");
+PIO_printf(interpreter, "DATA=> %ld\n", 
PMC_int_val(key));
+PIO_printf(interpreter, "   },\n");
+break;
+case KEY_number_FLAG:
+PIO_printf(interpreter, "TYPE=> NUMBER\n");
+ct_index = PackFile_find_in_const(interpreter, ct, key, 
PFC_NUMBER);
+PIO_printf(interpreter, "PFC_OFFSET  => %ld\n", 
ct_index);
+detail = ct->constants[ct_index];
+PIO_printf(interpreter, "DATA=> 

Re: class interface of roles

[Sam Vilain]

TSa wrote:
> HaloO,
>
> is this subject not of interest? I just wanted to start a
> discussion about the class composition process and how a
> role designer can require the class to provide an equal
> method and then augment it to achieve the correct behavior.
> Contrast that with the need to do the same in every class
> that gets the equal method composed into if the role doesn't
> have a superclass interface as described in the article.
>   

This will be the same as requiring that a class implements a method,
except the method's name is infix:<==>(::T $self: T $other) or some such.

Sam.

Re: [perl #40429] [PATCH] test for perl code coda

[Paul Cochrane]

Will,


Thank you for your work on this: it's a solid patch, I'd apply it...

... But I've just rolled this test into the recently added 
t/codingstd/perlcritic.t by way of a
Perl::Critic policy class that's been added to the repo.

Please don't be discouraged. =-)

I'm not!  :-)  Thanks for the pointer, I'll have a look at the new
test to see how it's integrated.


Regards, and thanks!

No worries :-)  Only too pleased to help.

Regards,

Paul

[perl #40443] Separate vtable functions from methods (using :vtable)

[via RT]

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


At the OSCON 2006 Hackathon, it was decided that we should separate  
vtables from methods and add a new :vtable label for PIR subs to mark  
them as vtable functions. This gets rid of the current namespace  
pollution caused by vtables and allows us to abandon the leading  
underscores for PIR vtable functions.

 .sub get_string :vtable
 .return("end namespace pollution!")
 .end

It appears that this never made it into RT.

--
Matt Diephouse

Perl 6 mailing list summary, 24-30 September, 2006

[Ann Barcomb]

 This week on the Perl 6 mailing lists

"And here I thought you were a responsible, law-abiding citizen... :P "

-- Jonathan Lang, commenting on Larry Wall's `self.HOW does Hash`


 Language

  class interface of roles 

TSa wondered how typing of mixins  would look in
Perl 6. A code example of how it might look was included. There were
also some questions on roles in Perl 6.

  Capture Literals 

Responding to an earlier thread, Austin Hastings asked if Capture
literals would replace or unify "assuming"/"currying".

  Motivation for /+/ set Array not Match? 

In a previous week, Audrey Tang quoted a section of S05 concerning
subrules. She found the 'quantified' clause to be unintuitive and
wondered if it would be possible to modify it to produce Match objects
and to reserve Array only for noncontiguous same-name subrules.
Patrick R. Michaud and Flavio S. Glock made some alternate
suggestions.

More recently Audrey replied to the thread, wondering if there was a
hidden cost to making `/+/` always react so that `$.from`
returns something. Masak preferred the proposed semantics and asked if
the question had been discussed off-list.

  Nitpick my Perl6 - parametric roles 

Sam Vilain sent some code on Perl 6 core types as collections and
asked if anyone would like to poke holes in it. TSa applauded the use
of functions but wondered if it would work. Several other people
followed up on that thought.

  Mutability vs Laziness 

Aaron Sherman pursued a conversation which began in IRC. He listed
some immutable types declared in S06 and noted that there appear to be
three core attributes (Mutability, Laziness and Ordered), each of
which has two states (true or false). From this he derived 8 types of
containers.

Dave Whipp thought there was a fourth attribute, exclusivity. Sam
Vilain felt that ordered was not an attribute of a collection.

  [svn:perl6-synopsis] r12398 - doc/trunk/design/syn 

In a recent commit, Larry Wall removed the special `[,]`, which is now
just a list op form of `[...]`. In order to support the `|func()`
syntax, `|` became the new disigilized `*`.

Luke Palmer replied in support of the new syntax. TSa also approved,
but would have liked the new operator spelled. Aaron Crane thought
that was undesirable because there are already terms which begin with
`/`, namely regular expressions.

  Common Serialization Interface 

Brad Bowman wondered if there was a common element to a serialization
role which could be included in the default implementation. Mark
Stosberg noted that there is already a `.yaml` and a `.perl` to
serialize to these formats, but he did not know if they were suitable
substitutes for the role-based approach Brad had in mind. He included
a code sample. Aaron Sherman and Luke Palmer offered additional code
examples. Larry Wall commented that it makes a big difference whether
the entire string must be held in memory or not.

  [svn:perl6-synopsis] r12417 - doc/trunk/design/syn 

Audrey Tang committed a change which introduced the `$$x` form in
adverbial pair parsing to S02 and canonicalized the term 'item' in S02
and S04.

  [svn:perl6-synopsis] r12432 - doc/trunk/design/syn 

In S03, Audrey Tang noted that chained comparisons short-circuit and
never evaluate arguments more than once.

  RFC: multi assertions/prototypes: a step toward programming by contract
  

Aaron Sherman wrote to suggest a signature prototype that all multis
defined in or exported to the current namespace must match, as a means
of implementing the paradigm of programming by contract.

Trey Harris felt that the point of multiple dispatch is that arguments
are not bound to a single type, and the proposal might defeat this
use, although junctive types, subsets and roles make 'single type'
less of a constraint. Miroslav Silovic was bothered by the possible
duplication of functionality and believed that declarative
requirements should go in to roles. Many other people responded to
this thread.

In addition, there was a discussion on the terminology of libraries in
Perl 5 and Perl 6--'package' being the Perl 5 term, and 'module' the
Perl 6 term. The definition of 'programming by contract' was also
discussed.

There was also a discussion on whether 'package' implied a Perl 5
library and 'module' suggested a Perl 6 one. Larry Wall attempted to
clarify.

  special named assertions 

David Brunton posted about an IRC conversation from earlier. He listed
the seven special named assertions found in S05, and the twenty-fo

Abstract roles, classes and objects

[Aaron Sherman]

Trey Harris wrote:

In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:

That said, this is a different point, above and I think it's an easy 
one to take on.


role A { method x() {...} }
class B { does A; }

does generate an error per "If a role merely declares methods without 
defining them, it degenerates to an interface:" from S12.


However, that's not to say that a class can't be abstract, just that 
a class that does an interface (a role with nothing but abstract 
methods) must implement the role's interface.


So why would it generate an error?  Why wouldn't it merely result in B 
being abstract too, assuming that contra my prior mail, classes can be 
abstract?


What use is an interface if it doesn't give you a guarantee? If I say, 
"all dogs can bark," and you define a dog that can't bark, that's not 
"abstract", that's a failure to meet the interface requirements of a dog.


Now, I *could* see a class being explicitly abstract. That is, defining 
its own incomplete method. At that point, I have met the interface 
requirement, but explicitly stated that my interface is incomplete. I'm 
not sure that that has an particular standing in the language though. 
That is, you could instantiate such a class and invoke the method in 
question. Only at runtime would the invocation result in an error, and 
perhaps you did all of this because, at runtime, you will mix in a class 
or role that delivers the promised functionality:


role ripens { method ripen() {...} }
role vine_ripened { method ripen($self:) { $self.organic //= 1 } }
role fruit { does ripens; method ripen() {...} }
my fruit $orange .= new();
$orange.ripen; # error
$orange does vine_ripened;
$orange.ripen; # Now we can, though "organic" needs defining

The idea of abstract objects is certainly compelling, but I don't think 
it's something we'll want to do without substantial explicitness.



  role A  { method x() { ... } }
  class B { does A; method x() { ... } }


And here you do just that.


Certainly this:

class A { method x() {...} }

is very explicit, and should be allowed, given that it is a promise 
that "sometime before x is called, it will be defined." It's a 
runtime error if that promise is not kept.


Did you mean to have "class B" and "does A" there


You seem to be parsing multiple examples statefully. I recommend against 
that.


On your last point, I think you are confusing an incomplete PRE (one 
which invokes yadda) and an undefined PRE slot in a method. The latter 
must be detectable as distinct for exactly the reasons you state.

Re: [svn:parrot-pdd] r14784 - trunk/docs/pdds/clip

[Karl Forner]

Hi all,



It crossed my mind that we could do this, but I rejected it since it's

not really helpful. The #! line is generally only applicable to UNIX-y
systems. Even on those systems that do support it, the path to Parrot
won't always be the same either.



Just a little trick that can help. If the parrot interpreter in in your
path, you can workaround
the need to specify the aboslute path by using the env command.
For instance:
#! /usr/bin/env parrot

I used that trick to enable the use of perl scripts in a multi-platform but
shared filesystem environment.


My 2 cents...
Karl Forner

Re: Motivation for /+/ set Array not Match?

[Carl Mäsak]

Audrey (>), Carl (>>):

> Has this been settled or addressed off-list?

'fraid not yet...


Ah. So Warnock applies.

(Side note: when I first read "Warnock applies" on things in p6
summaries a year or so ago, I thought it was some really energetic
programmer who went around and applied patches as soon as people posed
a question. Turned out that wasn't the case...)




> Because from my perspective as one who has never used P6 rules for
> anything
> in particular, but who in the future most likely will, the proposed
> semantics seems a lot saner and more useful. It'd be sad to let pass
> this opportunity to fix (what from my perspective appears to be) a
> shortcoming of the rule semantics.

*nod* The lack of .from/.to is merely an annoyance, but the spaced-out
stringification is really, really surprising with /+/.


Do you have a short snippet to illustrate this?

--
masak

Re: Motivation for /+/ set Array not Match?

[Audrey Tang]

在 Sep 28, 2006 3:03 AM 時，Carl Mäsak 寫到：


Audrey (>):
Indeed... Though what I'm wondering is, is there a hidden  
implementation

cost or design cost of making /+/ always behave such that
$.from
returns something, compared to the current treatment with the  
workaround

you suggested?


Has this been settled or addressed off-list?


'fraid not yet...

Because from my perspective as one who has never used P6 rules for  
anything

in particular, but who in the future most likely will, the proposed
semantics seems a lot saner and more useful. It'd be sad to let pass
this opportunity to fix (what from my perspective appears to be) a
shortcoming of the rule semantics.


*nod* The lack of .from/.to is merely an annoyance, but the spaced-out
stringification is really, really surprising with /+/.

Thanks,
Audrey

[perl #40438] Extending a dynpmc with a PIR method fails

[Leopold Toetsch via RT]

Thanks, I've applied a modified version of the patch, showing that it's
a namespace issue caused by the .HLL line. Using .loadlib works fine and
as expected.

leo

Re: Synopses on the smoke server are a bit out-of-date

[Ingo Blechschmidt]

Hi,

Agent Zhang wrote:
> On 9/28/06, Agent Zhang <[EMAIL PROTECTED]> wrote:
>> lanny noticed yesterday that the Synopses on the smoke server were
>> different from the ones on feather. Because I am maintaining the
>> feather ones, I know the synopses there are being resync'd every hour
>> as expected.
> Now the synopses on the smoke server is ~50 rev behind but the
> timestamp looks good. What's wrong with it?

could you please point to an example smoke?

See for example http://xrl.us/rzp7, http://xrl.us/rzp8,
http://xrl.us/rzp9, smokes several days old.

The timestamps indicates a refresh run a few hours ago, and the syn rev
is r12533. According to

  svn log -v http://svn.perl.org/perl6/doc/trunk/design/syn | head

r12533 is indeed the current revision.


(Many thanks to malon++!)

--Ingo

Re: Automatic coercion and context

[Jonathan Lang]

Jonathan Scott Duff wrote:

I hope you're way off the mark. Automatic coercion was one of the
annoyances I remember from C++. Debugging becomes more difficult when
you have to not only chase down things that are a Foo, but anything
you've compiled that might know how to turn itself into a Foo.


OTOH, there is a time and place for so-called "automatic" coercion,
such as the way that perl freely converts between Str and Num.
Indeed, ISTR something about standardized stringifying and numifying
method names that let _any_ object turn into a string or number (or
boolean, IIRC) when placed in the appropriate context.  And I can see
some benefit to extending this ability to other types, as long as it's
used sparingly.  In particular, I'm thinking about complex numbers -
it would be nice to see perl convert between the rectilinear and polar
representations of complex numbers in the same way that it converts
between Num and Str.

--
Jonathan "Dataweaver" Lang