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:


I'm not sure about this last comment -- I think I can imagine
that other language implementations (including new ones we haven't
thought of yet but suddenly becomes possible with Parrot) might 
want to make use of gather/take semantics if they're readily available --

especially because they can be very hard to otherwise
implement when they're not readily available.  And compile-time
constants are pretty cheap.  :-)


Absolutely. But for that it shouldn't be called "CONTROL_TAKE", because 
that's meaningless outside Perl 6.



So, I think we can't always say "oh, only one dynamic language
needs this feature so it shouldn't be global" -- we need to also
consider those dynamic-languages-yet-to-be-written because Parrot
is such an incredible platform for creating them.


Yes, that's not the principle. The principle is that global things 
should be language-agnostic, and not use terminology that's confusing to 
all the other languages.


Allison

Re: ExceptionHandler enhancement proposal

[Allison Randal]

Bob Rogers wrote:


   Yes, once we have the ability to have exception handlers only handle 
   specific types of exceptions, then they'll allow all other types of 
   exceptions to pass through. (Which means we won't end up with the 
   infinite exception handler loops we currently get if exception handlers 
   aren't disabled as soon as they're used.)


Are you sure?  What if the body of a catch-all error handler signals an
error?  Methinks the handler must truly be taken out of scope before it
is invoked in order to avoid infinite exception handler loops.


Yes, of course a catch-all exception handler will always catch all 
exceptions. But, a catch-all exception handler is intended to catch all 
exceptions, and therefore can't make any assumptions about the exception 
object other than the defined standard exception interface.


The problem now isn't that the same exception handler is being called 
twice (once on the first exception, and once on the exception thrown 
from within the handler). The problem is that the exception handlers 
were written assuming that they'd only ever get one kind of exception. 
When they get a different kind of exception the second time, they aren't 
expecting it, and make some terrible mistake, which throws another 
exception, but they don't know how to handle that one and make a 
terrible error and throw another exception, and so get themselves into 
an infinite loop.


   The 'can_handle' method is the only required interface for checking 
   whether a particular handler will accept a particular exception. All 
   other checks should be hidden behind that method.


Hmm.  The only way to find out whether a Lisp handler will handler a
given exception is to call it; if the answer is yes, it will never
return.  So I'm hoping a 'can_handle' method that either returns false
or transfers control to somewhere else can be made to work.


For that, you would implement a catch-all handler (completely ignoring 
'can_handle'), and then rethrow any exceptions you can't handle.


Allison

Re: How to define a new value type?

[Daniel Ruoso]

Ter, 2008-09-16 às 20:07 -0500, John M. Dlugosz escreveu:
> Yes, with immutable objects you don't have to clone it.  Multiple copies 
> can be shared.
> By making "value types" as described above also immutable, it formally 
> removes all distinction between reference assignment and value assignment.

I've been presuming that for SMOP, actually...

daniel

[perl #58952] Implemented second argument to comb

[Chris Davaz]

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


Here is the implementation of the second argument to the comb method as
described in S29. Here is a test I wrote (which I'll commit to the pugs test
suite later):

my Str $hair = "Th3r3 4r3 s0m3 numb3rs 1n th1s str1ng";
say $hair.comb(/\d+/);
say $hair.comb(/\d+/, -10);
say $hair.comb(/\d+/, 0);
say $hair.comb(/\d+/, 1);
say $hair.comb(/\d+/, 3);
say $hair.comb(/\d+/, 9);
say $hair.comb(/\d+/, 1);

The output being:

3343033111


3
334
334303311
3343033111
Index: src/builtins/any-str.pir
===
--- src/builtins/any-str.pir	(revision 31199)
+++ src/builtins/any-str.pir	(working copy)
@@ -45,6 +45,8 @@
 
 .sub comb :method :multi(_)
 .param pmc regex
+.param int count:optional
+.param int has_count:opt_flag
 .local pmc retv, match
 .local string s
 
@@ -54,6 +56,10 @@
   do_match:
 match = regex.'ACCEPTS'(s)
 unless match goto done
+unless has_count goto skip_count
+count -= 1
+if count < 0 goto done
+  skip_count:
 # shouldn't have to coerce to Str here, but see RT #55962
 $S0 = match
 retv.'push'($S0)

[perl #53536] [PATCH] sub-second sleep precision for non-threaded architectures

[Christoph Otto via RT]

On Mon Sep 15 20:08:38 2008, [EMAIL PROTECTED] wrote:
> chromatic wrote:
> > On Monday 15 September 2008 01:25:15 Christoph Otto via RT wrote:
> >
> >> It applies with a little noise to the current trunk and passes make
> >> test.  The attached version just changes line numbers so the patch
> >> applies without any complaints (plus a codingstd fix).
> >> +1 for applying, fwiw.
> >
> > +1 as well, if someone replaces the "Not yet documented" lines with
> > documentation (man usleep should help).
> >
> > -- c
> >
> 
> I'll be applying the attached the patch after tomorrow's release, if
> someone
> doesn't beat me to it.

Done.  Thanks for the patch!

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

[Christoph Otto via RT]

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.

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

[Stephen Weeks]

Not long ago, Patrick R. Michaud proclaimed...
> I'm not sure about this last comment -- I think I can imagine
> that other language implementations (including new ones we haven't
> thought of yet but suddenly becomes possible with Parrot) might 
> want to make use of gather/take semantics if they're readily available --
> especially because they can be very hard to otherwise
> implement when they're not readily available.  And compile-time
> constants are pretty cheap.  :-)

I plan to add support for gather/take to cardinal.  While we're
discussing it, though, it might be fun to add it to lolcode, for
purposes of flashy inter-hll demos.

[perl #58948] [BUG] multi subs compile but cause segfault

[Stephen Simmons]

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


Using the more elaborate version of the testcase behind #58294, which has a
two and a three argument version of max, what use to compile and execute
incorrectly before the bug fix now compiles and segfaults.  I suspect this
has nothing to do with the changes that fixed #58294, and everything to do
with recent MMD changes.  But that's speculation
I've stripped it down to the max(a,b) and max(a,b,c) definitions and one
three-arg call, though a two-arg call produces a similar result.  The result
is:

sully:perl6 stephensimmons$ perl6 experiment/max3.p6
Null PMC access in invoke()
current instr.: '_block11' pc 44 (EVAL_14:19)
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;command_line' pc 1257
(src/PCT/HLLCompiler.pir:699)
called from Sub 'parrot;Perl6::Compiler;main' pc 16414 (perl6.pir:172)
perl6(22765) malloc: *** error for object 0x343ea10: double free
*** set a breakpoint in malloc_error_break to debug
Segmentation fault

sysinfo:
sully:perl6 stephensimmons$ perl6 -v
This is Rakudo Perl 6, revision 31194 built on parrot 0.7.0-devel
for darwin-thread-multi-2level.

Copyright 2006-2008, The Perl Foundation.

sully:perl6 stephensimmons$ uname -a
Darwin sully.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53
PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386

Note that this does not segfault in r30669, though it does not handle
defined correctly.


max3.p6
Description: Binary data

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

[Carl Mäsak]

Rakudo and I have a disagreement over this: I expect to be able to
assign to a $.foo attribute in methods within the class, whereas
Rakudo demands the "is rw" attribute in order to do that.

We discussed it a bit on #perl6 today.

 

I only have pragmatic arguments to offer for my point of view:
somehow, it feels like each and every attribute gets an "is rw" as
things stand now. The modifier somewhat loses its meaning... if it
meant "_publicly_ readable/writable", it would only be used for some
variables.

(I may have to rethink the above reason when attribute initialization
(as in "has $.foo = 5") is fully implemented in Rakudo.)

The other argument is that I (for some reason) expect a $.foo variable
to be changeable from within the class -- even when it doesn't have an
"is rw" attribute. It's one of those presuppositions which keeps
biting me when writing classes. I know I could use "$!foo"
consistently, and things will work, but... then I have to remember to
write "$.foo" when declaring the variable and "$!foo" when using it.

Finally, some useless statistics: I count 12 attributes in different
classes in November right now. Out of those, 12 (100%) have the "is
rw" attribute.

// Carl

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

[Moritz Lenz]

Just to bring some of the IRC discussion to the list...

Carl Mäsak wrote:
> Rakudo and I have a disagreement over this: I expect to be able to
> assign to a $.foo attribute in methods within the class, whereas
> Rakudo demands the "is rw" attribute in order to do that.
> 
> We discussed it a bit on #perl6 today.
> 
>  
> 
> I only have pragmatic arguments to offer for my point of view:
> somehow, it feels like each and every attribute gets an "is rw" as
> things stand now. The modifier somewhat loses its meaning... if it
> meant "_publicly_ readable/writable", it would only be used for some
> variables.

There's also the point that you can initialize attributes with the . twigil:

class Stuff { has $.more_stuff = 3 }

So at least visually it appears as though you *can* assign to it. Not
allowing that in other places feels weird.

Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just
fake assignment to '$.foo' to actually affect '$!foo'?

> Finally, some useless statistics: I count 12 attributes in different
> classes in November right now. Out of those, 12 (100%) have the "is
> rw" attribute.

This is mostly probably due to non-working constructors. Simple cases
seem to work, though:

12:29 < moritz_> rakudo: class A { has $.b }; my A $x .= new(b => 3);
say $x.b
12:29 < p6eval> rakudo 31204: OUTPUT[3␤]

Moritz

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

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

[Jonathan Worthington]

Moritz Lenz wrote:

Yes, I know that $.stuff actually translates to $( self.stuff ), so
without 'is rw' there is no rw accessor generated - but couldn't we just fake 
assignment to '$.foo' to actually affect '$!foo'?
  
Why not just assign to $!foo, which is always read/write (since the rw 
affects whether you get an accessor that is read/write or not - $!foo 
refers to the underlying storage location; at least, that's how I 
understand it and what I think Rakudo is implementing today).


Jonathan

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

[Carl Mäsak]

Jonathan (>):
> Why not just assign to $!foo, which is always read/write (since the rw
> affects whether you get an accessor that is read/write or not - $!foo refers
> to the underlying storage location; at least, that's how I understand it and
> what I think Rakudo is implementing today).

I have come to understand that this is an available possibility, yes.
That doesn't mean I like it. :)

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"

// Carl

Re: How to define a new value type?

[TSa]

HaloO,

Moritz Lenz wrote:

When you read carefully through S29 you'll notice that most methods in
immutable classes (like Str, List, Int) only return modified copies,
even if they mutate the string in Perl 5.


Great!


(There are some exceptions like Str.substr, which explicitly 'is rw',
and which implies that the object somehow has to gain access to its
container).


Reading the description there I wonder how this is supposed to work.

   our Str multi method substr (Str $string: StrPos $start, Int 
$length)

 is rw is export

   $string ~~ /(barney)/;
   substr($string, $0.from, $0.to) = "fred";

The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?

   my $a = "His name is barney";
   my $b = $a;

   $a ~~ /(barney)/;
   substr($a, $0.from, $0.to) = "fred";

   say $b; # prints fred?

If substr should get access to the container passed as argument then
the signature should read

   our Str multi method substr (Str $string is rw: StrPos $start,
Int $length) is rw is export

and the docu should say that the result is written into the container
passed in the invocant slot. But the 'is rw' on the invocant has the
drawback that calling with a string literal is precluded.


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?

[Moritz Lenz]

TSa wrote:
> The 'is rw' is on the method but I guess it is foreseen that the
> result is stored in $string without preserving the identity of the
> string?

No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy in it. If that fails (for
example in "abc".substr(0, 1) = "foo", where "abc" isn't in a container
at all) the write operation will fail.

> my $a = "His name is barney";
> my $b = $a;
> 
> $a ~~ /(barney)/;
> substr($a, $0.from, $0.to) = "fred";
> 
> say $b; # prints fred?

No, the match object needs to be bound to the value (which is immutable)
unless the :rw modifier is present.

> If substr should get access to the container passed as argument then
> the signature should read
> 
> our Str multi method substr (Str $string is rw: StrPos $start,
>  Int $length) is rw is export
> 
> and the docu should say that the result is written into the container
> passed in the invocant slot. But the 'is rw' on the invocant has the
> drawback that calling with a string literal is precluded.

Makes sense to me. (The Int should really be StrLen, but that's only a
minor glitch).

That said, much of S29 needs some loving care...

Moritz

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

[perl #58742] [TODO] Marker for RTs re SmartLinks

[James Keenan via RT]

On Tue Sep 16 15:45:47 2008, [EMAIL PROTECTED] wrote:
> 
> 2.  I will apply a refined version of the patch.  It will delete inline
> comments referring to the deleted tickets.  But I will leave to others
> dealing with reference to smartlinks under languages/.

Done, now that release has been cut.

> 
> 
> 4.  I will then open up a new RT of the [RFC] class.  This ticket will
> call for development of a specification of a way to visually display the
> extent to which Parrot's tests cover the specification.  I'll be quoting
> from particle's post -- but I'm sure there will be additional questions
> for Jerry.  The spec will call for a way to test whatever code we
> develop to meet the spec.  So, rather than asking people to rush out to
> write code, we'll focus first on determining what we want and need.
> 

Still TODO.

Questions about :multi in Method Signatures

[Chris Davaz]

I am confused about how we should setup method signatures:

Let's take a look at a line in any-str.pir:

 46 .sub 'comb' :method :multi(_)
 47 .param pmc regex
 48 .param int count:optional
 49 .param int has_count:opt_flag

As you can see we have one parameter specified in :multi which is _ (any
type). However we also have two .param lines, 47 and 48. So here are some
questions:

I noticed 'self' is implicitly defined, however does 'self' eat up a
parameter? Should we always have one parameter in :multi specified for the
object the method is running on?

Also, I played around with :multi by putting in different things. With the
above method here is what I tried and the result

:multi(_) - works
:multi(_, _) works
:multi(_,_,_) doesn't work
:multi(_,Integer) doesn't work
:mult(Sub) doesn't work

Some clarification surrounding the use of :multi would help a lot.

Best Regards,
-Chris Davaz

[perl #58958] Build of 0.7.1 fails with Intel compiler on Linux

[[EMAIL PROTECTED] (via RT)]

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


I'm trying to build Parrot 0.7.1 with Intel Compiler (see version
information below). The operating system is Ubuntu 8.04, 64-bit. Build
succeeds with GCC (4.2.3 installed). Parameters to Configure.pl are as
follows:

perl Configure.pl --cc=icc --cxx=icc --ld=icc 

I have four versions installed under /opt: 9.1.042 in 32 and 64-bit;
10.1.015 in 32 and 64-bit. (Switching between them using the method
recommended by Intel: source iccvars.sh.) I have been successful in
compiling previous versions of Parrot with icc in the past; I think
0.6.4 was the last one that worked. 

For both 32-bit versions, Configure.pl fails at:

--cut--

init::manifest -  Check
MANIFEST.done.
init::defaults -  Set Configure's default
values.done.
init::install -   Set up installation
paths..done.
init::miniparrot -Tweak settings for
miniparrot...skipped.
init::hints - Load platform and local hints
filesdone.
init::headers -   Find header files distributed with
Parrot..done.
inter::progs -Determine what C compiler and linker to
use...Compilation failed with 'icc'

--cut--

I have been unable to enable Configure.pl to produce more output, or the
error messages themselves. 32-bit icc works fine when compiling other
programs on the same system.

For 64-bit 9.1.042 and 10.1.015, I get the following error:

--cut--

/usr/bin/perl5.8.8 tools/build/c2str.pl --all
src/string.c
src/ops/core_ops.c
src/ops/core_ops_switch.c
src/byteorder.c
src/charset.c
src/core_pmcs.c
src/cpu_dep.c
src/datatypes.c
src/debug.c
src/debug.c(1384): warning #593: variable "regleft" was set but never
used
  unsigned charregleft;
   ^

src/dynext.c
src/embed.c
src/encoding.c
src/events.c
src/exceptions.c
src/exceptions.c(74): error: identifier "_CONST_STRING_74" is undefined
  VTABLE_set_integer_keyed_str(interp, exception,
  ^

src/exceptions.c(76): error: identifier "_CONST_STRING_76" is undefined
  VTABLE_set_integer_keyed_str(interp, exception,
  ^

src/exceptions.c(106): error: identifier "_CONST_STRING_106" is
undefined
  const INTVAL severity = VTABLE_get_integer_keyed_str(interp,
  ^

src/exceptions.c(125): error: identifier "_CONST_STRING_125" is
undefined
  exit_status = VTABLE_get_integer_keyed_str(interp,
^

src/exceptions.c(276): error: identifier "_CONST_STRING_276" is
undefined
  int exitcode = VTABLE_get_integer_keyed_str(interp, exception,
 ^

src/exceptions.c(287): warning #191: type qualifier is meaningless on
cast type
  (Parrot_runloop * const)VTABLE_get_pointer(interp,
  handler);
   ^

src/exceptions.c(401): error: identifier "_CONST_STRING_401" is
undefined
  VTABLE_set_integer_keyed_str(interp, exception,
  ^

compilation aborted for src/exceptions.c (code 2)
make: *** [src/exceptions.o] Error 2

--cut--

Will provide more information on request.

-- 
Ville Koskinen

Re: [perl #58958] Build of 0.7.1 fails with Intel compiler on Linux

[chromatic]

On Wednesday 17 September 2008 04:48:59 [EMAIL PROTECTED] (via RT) wrote:

> src/exceptions.c(74): error: identifier "_CONST_STRING_74" is undefined
>       VTABLE_set_integer_keyed_str(interp, exception,

This one means that ICC handles #line directives differently.  If you manually 
edit this line to remove the linebreak before CONST_STRING, does ICC still 
give an error here?

-- c

Re: Parrot 0.7.1 "Manu Aloha" released

[Francois Perrad]

Patrick R. Michaud a écrit :

On behalf of the Parrot team, I'm proud to announce Parrot 0.7.1
"Manu Aloha." Parrot (http://parrotcode.org/) is a virtual machine aimed
at running all dynamic languages.

As usual, the Windows setup is available on 
http://parrotwin32.sourceforge.net/


François.


Parrot 0.7.1 is available via CPAN (soon), or follow the download
instructions at http://parrotcode.org/source.html .  For those who would 
like to develop on Parrot, or help develop Parrot itself, we recommend 
using Subversion on the source code repository to get the latest and 
best Parrot code.


Parrot 0.7.1 News:
- Implementation
  + add -I and -L command line options
  + support for null strings in NCI calls
  + preliminary support for resumable exceptions
  + add '.hll_map' method for dynamic HLL type mapping
  + more parrot_debugger fixes
  + remove obsolete '.past' extension
- Languages
  + Rakudo (Perl 6)
- now over 3300 passing spectests
- precompiled modules
- precompiled scripts  (--target=pir can now be executed standalone)
- Support for @*INC and %*INC varialbes
- additional builtin methods and subs
- added 'fail' function, warnings on use of undefined values
- m/.../ regexes
- qq, qw, q quoting forms
- run tests in parallel
- gather/take
- Perl6MultiSub
  + Cardinal (Ruby):
- 'require' and precompiled modules
- many new tests
- all Array tests pass
- regexes
- default arguments to functions
- new committer
- Compilers
  + PCT:
- add :loadinit attribute for PAST::Block
  + PIRC:
- major refactoring to allow all PIR keywords as identifiers
- links to libparrot now, so all Parrot ops are recognized as such
- implemented .loadlib, .HLL_map, .HLL
- Miscellaneous
  + add Xlib and Mysql modules and test programs to NCI examples
  + many updates and cleanups to PDD documents


Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project.  Our next scheduled release is 21 Oct 2008.

Enjoy!

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

[Patrick R. Michaud]

On Wed, Sep 17, 2008 at 10:57:31AM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
>>
>> I'm not sure about this last comment -- I think I can imagine
>> that other language implementations (including new ones we haven't
>> thought of yet but suddenly becomes possible with Parrot) might want to 
>> make use of gather/take semantics if they're readily available --
>> especially because they can be very hard to otherwise
>> implement when they're not readily available.  And compile-time
>> constants are pretty cheap.  :-)
>
> Absolutely. But for that it shouldn't be called "CONTROL_TAKE", because  
> that's meaningless outside Perl 6.  
> [...]
> The principle is that global things  
> should be language-agnostic, and not use terminology that's confusing to  
> all the other languages.

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

Pm

Re: Questions about :multi in Method Signatures

[Patrick R. Michaud]

On Wed, Sep 17, 2008 at 08:37:36PM +0800, Chris Davaz wrote:
> I am confused about how we should setup method signatures:
> 
> Let's take a look at a line in any-str.pir:
> 
>  46 .sub 'comb' :method :multi(_)
>  47 .param pmc regex
>  48 .param int count:optional
>  49 .param int has_count:opt_flag
> 
> As you can see we have one parameter specified in :multi which is _ (any
> type). However we also have two .param lines, 47 and 48. So here are some
> questions:
> 
> I noticed 'self' is implicitly defined, however does 'self' eat up a
> parameter? Should we always have one parameter in :multi specified for the
> object the method is running on?

Yes, the first argument of the :multi refers to the invocant.

> Also, I played around with :multi by putting in different things. With the
> above method here is what I tried and the result
> 
> :multi(_) - works

Restricts the sub to being invoked by callers supplying
at least one argument (in this case, the argument is the
invocant, since the sub is declared as :method).

> :multi(_, _) works

This says that the sub requires at least two arguments (of any
type).  The first will go into 'self', the second into 'regex'.

> :multi(_,_,_) doesn't work

This says that the sub requires at least three arguments (of
any type).  This doesn't really match the sub definition though,
which has an invocant, a required argument, and an optional argument.

> :multi(_,Integer) doesn't work

This says the invocant may be of any type, and the first argument
must be an Integer (or a subclass of Integer).  Probably not what
we want given that the first parameter of the sub is 'regex'.


> :mult(Sub) doesn't work

This says that the sub can be invoked only on Sub invocants.

> Some clarification surrounding the use of :multi would help a lot.

Hope the above helps.  I don't know where :multi is documented in
Parrot itself; the pdd27 file doesn't provide much detail.

Pm

Re: [perl #58948] [BUG] multi subs compile but cause segfault

[Patrick R. Michaud]

On Tue, Sep 16, 2008 at 09:01:06PM -0700, Stephen Simmons wrote:
> Using the more elaborate version of the testcase behind #58294, which has a
> two and a three argument version of max, what use to compile and execute
> incorrectly before the bug fix now compiles and segfaults.  I suspect this
> has nothing to do with the changes that fixed #58294, and everything to do
> with recent MMD changes.  But that's speculation
> I've stripped it down to the max(a,b) and max(a,b,c) definitions and one
> three-arg call, though a two-arg call produces a similar result.  The result
> is:
> 
> sully:perl6 stephensimmons$ perl6 experiment/max3.p6
> Null PMC access in invoke()
> current instr.: '_block11' pc 44 (EVAL_14:19)

I think there's something wrong with Rakudo's code generation
here; see the --target=pir output for max3.p6.  The code generated 
for the 2-arg and 3-arg forms of max are coming out as:

## 2 argument form
.sub "max"  :multi() :lexid("25") :outer("23")
.param pmc param_16
.param pmc param_19


## 3 argument form
.sub "max"  :multi() :lexid("33") :outer("23")
.param pmc param_101
.param pmc param_104
.param pmc param_107

Those two empty :multi() declarations look very suspicious to me,
but I'm not familiar enough with the new MMD implementation to know
how it's supposed to work.

Pm

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

[jerry gay]

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

Re: How to define a new value type?

[TSa]

HaloO,

Moritz Lenz wrote:

TSa wrote:

The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?


No. It means that the Str object has to get hold of the container in
which it is stored, and store a modified copy in it. If that fails (for
example in "abc".substr(0, 1) = "foo", where "abc" isn't in a container
at all) the write operation will fail.


Sorry, I don't understand why you say 'no' and then explain that the
resulting new string is stored in the container. The only container
that could be affected by this is $string in the example. The way for
a method to get access to the container is by declaring a parameter
as rw. Note that this brings the discussion back to the point how rw
is handled in dispatch and if an anonymous container is autovivified
for a naked value. Did you mean the 'no' as answer to the question if
the identity of the string--i.e. its pointer--is preserved? This would
violate the immutability assertion of string values.

Is it generally foreseen that an object knows about the containers
it is stored in? Furthermore is it informed which of these is currently
used as lvalue in a mutating operation? I think both are expensive and
much better handled through the rw declaration of parameters because
at binding time the container is available.


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: [perl #58948] [BUG] multi subs compile but cause segfault

[Patrick R. Michaud]

On Wed, Sep 17, 2008 at 10:01:12AM -0500, Patrick R. Michaud wrote:
> On Tue, Sep 16, 2008 at 09:01:06PM -0700, Stephen Simmons wrote:
> > Using the more elaborate version of the testcase behind #58294, which has a
> > two and a three argument version of max, what use to compile and execute
> > incorrectly before the bug fix now compiles and segfaults.  I suspect this
> > has nothing to do with the changes that fixed #58294, and everything to do
> > with recent MMD changes.  But that's speculation
> > I've stripped it down to the max(a,b) and max(a,b,c) definitions and one
> > three-arg call, though a two-arg call produces a similar result.  The result
> > is:
> > 
> > sully:perl6 stephensimmons$ perl6 experiment/max3.p6
> > Null PMC access in invoke()
> > current instr.: '_block11' pc 44 (EVAL_14:19)
> 
> I think there's something wrong with Rakudo's code generation
> here; see the --target=pir output for max3.p6.  [...]
> ## 2 argument form
> .sub "max"  :multi() :lexid("25") :outer("23")
> ## 3 argument form
> .sub "max"  :multi() :lexid("33") :outer("23")
> 
> Those two empty :multi() declarations look very suspicious to me,
> but I'm not familiar enough with the new MMD implementation to know
> how it's supposed to work.

I just checked with Jonathan on IRC, and he says the empty :multi()
declarations are correct here.  So that's not the problem.

Actually, I suspect the problem may be that 'max' is already a
builtin function in Perl, and that the conflict comes because
the builtins (written in PIR) are still using Parrot's MultiSub
while the ones written in Perl 6 are using the new Perl6MultiSub
implementation.  If I change the function name in max3.p6 to
be something other than 'max', it appears to work:

$ cat max3.p6
multi sub max3($a, $b) {
if defined $a && defined $b {
if $a >= $b { return $a } else { return $b }
}
elsif defined $a { return $a }
elsif defined $b { return $b }
else { return undef }
}

multi sub max3($a, $b, $c) {
return max3(max3($a, $b), $c);
}

say "6 <" ~ max3(9,2,1) ~ ">";
$ ./parrot perl6.pbc max3.p6
6 <9>
$

So, this problem should be "fixed" when we get the builtins to be
written in Perl 6 (or at least using Perl6MultiSubs).

Pm

Re: Questions about :multi in Method Signatures

[Chris Davaz]

That's a great response, thanks. Clears things up. One question, should be
always be using _ for the invocant or should we try to restrict it?

On Wed, Sep 17, 2008 at 10:52 PM, Patrick R. Michaud <[EMAIL PROTECTED]>wrote:

> On Wed, Sep 17, 2008 at 08:37:36PM +0800, Chris Davaz wrote:
> > I am confused about how we should setup method signatures:
> >
> > Let's take a look at a line in any-str.pir:
> >
> >  46 .sub 'comb' :method :multi(_)
> >  47 .param pmc regex
> >  48 .param int count:optional
> >  49 .param int has_count:opt_flag
> >
> > As you can see we have one parameter specified in :multi which is _ (any
> > type). However we also have two .param lines, 47 and 48. So here are some
> > questions:
> >
> > I noticed 'self' is implicitly defined, however does 'self' eat up a
> > parameter? Should we always have one parameter in :multi specified for
> the
> > object the method is running on?
>
> Yes, the first argument of the :multi refers to the invocant.
>
> > Also, I played around with :multi by putting in different things. With
> the
> > above method here is what I tried and the result
> >
> > :multi(_) - works
>
> Restricts the sub to being invoked by callers supplying
> at least one argument (in this case, the argument is the
> invocant, since the sub is declared as :method).
>
> > :multi(_, _) works
>
> This says that the sub requires at least two arguments (of any
> type).  The first will go into 'self', the second into 'regex'.
>
> > :multi(_,_,_) doesn't work
>
> This says that the sub requires at least three arguments (of
> any type).  This doesn't really match the sub definition though,
> which has an invocant, a required argument, and an optional argument.
>
> > :multi(_,Integer) doesn't work
>
> This says the invocant may be of any type, and the first argument
> must be an Integer (or a subclass of Integer).  Probably not what
> we want given that the first parameter of the sub is 'regex'.
>
>
> > :mult(Sub) doesn't work
>
> This says that the sub can be invoked only on Sub invocants.
>
> > Some clarification surrounding the use of :multi would help a lot.
>
> Hope the above helps.  I don't know where :multi is documented in
> Parrot itself; the pdd27 file doesn't provide much detail.
>
> Pm
>

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

[TSa]

HaloO,

Carl Mäsak wrote:

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"


Perhaps you should change your POV. The correct terminus
technicus for the $.foo twigil variables is 'call the method'
which nicely embeds attribute access into dispatch and makes
base methods future proof with respect to deriving classes.
Your 100% rw observation then to me indicates that OO is more
about data sharing than method dispatch. Note that rw accessors
are particularly difficult to handle in typesafe mode.


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: Questions about :multi in Method Signatures

[Patrick R. Michaud]

On Wed, Sep 17, 2008 at 11:48:54PM +0800, Chris Davaz wrote:
> That's a great response, thanks. Clears things up. One question, should be
> always be using _ for the invocant or should we try to restrict it?

I suggest always using _ for the invocant, at least for now.

Pm

Re: Questions about :multi in Method Signatures

[Moritz Lenz]

Patrick R. Michaud wrote:
> On Wed, Sep 17, 2008 at 08:37:36PM +0800, Chris Davaz wrote:
>> I am confused about how we should setup method signatures:
>> 
>> Let's take a look at a line in any-str.pir:
>> 
>>  46 .sub 'comb' :method :multi(_)
>>  47 .param pmc regex
>>  48 .param int count:optional
>>  49 .param int has_count:opt_flag
>> 
>> As you can see we have one parameter specified in :multi which is _ (any
>> type). However we also have two .param lines, 47 and 48. So here are some
>> questions:
>> 
>> I noticed 'self' is implicitly defined, however does 'self' eat up a
>> parameter? Should we always have one parameter in :multi specified for the
>> object the method is running on?
> 
> Yes, the first argument of the :multi refers to the invocant.

I didn't know this (shame on me), which resulted in some brokenness, it
seems. Particularly Str.split looks like this:

.sub 'split' :method :multi('String')

Which should probably be

.sub 'split' :method :multi(_, 'String')

Sadly this change breaks Str.reverse, which calls split with empty
string on its invocant:

.sub 'reverse' :method :multi('String')
.local pmc retv

retv = self.'split'('')
retv = retv.'reverse'()
retv = retv.join('')

.return(retv)
.end

(With the "correct" signature for Str.split this dies with "no
applicable methods").

Moritz

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

Re: Chained Modifiers

[Larry Wall]

On Mon, Sep 15, 2008 at 12:16:22PM +0200, Moritz Lenz wrote:
: Chris Davaz wrote:
: > I'm not sure if it's anywhere in the specs, but I was expecting to be able
: > to do this:
: > 
: > .say for =$in unless $foo;
: 
: to quote http://perlcabal.org/syn/S04.html#Loop_statements
: 
: :Looping statement modifiers are the same as in Perl 5 except that, for
: :ease of writing list comprehensions, a looping statement modifier is
: :allowed to contain a single conditional statement modifier:
: :
: :@evens = ($_ * 2 if .odd for 0..100);
: 
: 
: > Where we have multiple modifiers, here "for" and "unless". Is this in the
: > specs? If yes, is it supposed to work in pugs or rakudo? If it's not in the
: > specs can we add it? ;-)
: 
: The "authoritative" source to ask if a piece of text is valid Perl 6 is
: STD.pm. It parses your example, but not as you might expect. Output from
: STD5_dump_match
: 
: :Unknown routines:
: :unless called at 1
: :comp_unit:
: : statementlist:
: :  statement:
: :   EXPR:
: :noun:
: : dotty:
: :  .
: :  dottyop:
: :   methodop:
: :longname:
: : name:
: :  identifier:
: :   say
: :
: :   statement_mod_loop:
: :for
: :modifier_expr:
: : EXPR:
: :  pre:
: :   prefix:
: :=
: :  noun:
: :   variable:
: :sigil:
: : sigil:
: :  $
: :desigilname:
: : longname:
: :  name:
: :   identifier:
: :in
: :
: :  statement:
: :   EXPR:
: :noun:
: : term:
: :  unless
: :  args:
: :
: :   arglist:
: :EXPR:
: : noun:
: :  variable:
: :   sigil:
: :sigil:
: : $
: :   desigilname:
: :longname:
: : name:
: :  identifier:
: :   foo
: :  ;\n
: 
: So 'unless' is actually parsed as a sub call.

That's obviously a bogus parse, and I even know how it happened
(because "unless" is currently considered a terminator that doesn't
distinguish between expression termination and statement termination),
but I'm not sure how to fix it yet.  It's possible that statement
modifiers should be demoted to very-low-precedence operators, but there
are some problems with that that I don't have enough brain to think
through at the moment.

Larry

[perl #58978] [TODO][IMCC] replace .result by .get_result

[via RT]

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


as suggested by Allison, .result in a .begin/end_call sequence will be
replaced by .get_result

[perl #58976] [TODO][IMCC] .arg will be replaced by .set_arg

[via RT]

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


as suggested by Allison, the .arg directive in a .begin_call/end_call
statement will be replaced by .set_arg

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

[Chris Davaz]

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


I say "initial" because it didn't pass one of my tests. This might be due to
regular expressions not being fully implemented, so if this is the case
please let me know. Once I know I'll fix my code if need by and write an
appropriate test case and add it to the pugs repo.

my Str $test = "theXbiggestXbangXforXtheXbuck";
my List $list = $test.split(/X/);
print $list.join("\n");
$test = "tagstripping";
# Expect the print to give us "tag stripping" however it just yields some
whitespace, not sure why
$list = $test.split(/\<\/?.*?\>/);
print $list.join(" ");
Index: src/classes/Str.pir
===
--- src/classes/Str.pir	(revision 31205)
+++ src/classes/Str.pir	(working copy)
@@ -46,7 +46,7 @@
 .return(retv)
 .end
 
-.sub 'split' :method :multi('String')
+.sub 'split' :method :multi(_, 'String')
 .param string delim
 .local string objst
 .local pmc pieces
@@ -76,6 +76,50 @@
 .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:
+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

[perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall

[via RT]

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


as suggested by Allison,
.return in a tailcall context, like this:

 .return foo()

will changed into:

 .tailcall foo()

[perl #58980] [TODO][IMCC] .return in a .begin/end_return will be replaced by .set_return

[via RT]

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


As suggested by Allison, in a .begin/end_return sequence, the .return
directive will be replaced by .set_return
Likewise .yield will become .set_yield in .begin/end_yield sequence.

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

[Larry Wall]

On Wed, Sep 17, 2008 at 01:00:07PM +0200, Carl Mäsak wrote:
: Jonathan (>):
: > Why not just assign to $!foo, which is always read/write (since the rw
: > affects whether you get an accessor that is read/write or not - $!foo refers
: > to the underlying storage location; at least, that's how I understand it and
: > what I think Rakudo is implementing today).
: 
: I have come to understand that this is an available possibility, yes.
: That doesn't mean I like it. :)
: 
: My complaint could be pithily summarized as "those are _my_,
: attributes, why can't I write to them?"

You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.  We take
similar 3rd-person viewpoints in natural language too, especially
when talking to kids:

Daddy thinks that's okay, but Amy will have to go ask Mommy too.

In C++ish OO terms, $.foo is always virtual, and $!foo is never
virtual.  The "has" declarator can intuit from a virtual $.foo
declaration that you also need private non-virtual $!foo storage,
but it can't intuit from a non-virtual declaration that you want to
have a public accessor, at least, not without more information than
the sigil provides, which would be uglier.

So $.foo basically says that you want to talk about the slot from
the viewpoint of the actual object, while $!foo says you want to talk
about the slot from the viewpoint of your class.  This is orthogonal
to the actual class boundary, if you ignore the fact that we prohibit
$!foo access from outside the class.  (And, in fact, we could probably
still get at it with a private method from outside the class if there
is an appropriate "trusts" declaration.)

Larry

Re: Parrot 0.7.1 "Manu Aloha" released

[Reini Urban]

http://www.parrotcode.org/release/devel still points to 0.7.0
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

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

[Moritz Lenz]

Chris Davaz (via RT) wrote:
> # New Ticket Created by  "Chris Davaz" 
> # Please include the string:  [perl #58970]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58970 >
> 
> 
> I say "initial" because it didn't pass one of my tests.

More importantly it introduces a regression in t/spec/S29-list/reverse.t
(Str.reverse is implemented in terms of split-into-characters -> list
reverse -> join; the split failed with your patch, thus causing a test
failure in 'make spectest_regression')

> This might be due to
> regular expressions not being fully implemented, so if this is the case
> please let me know. 

That's unlikely (but not impossible, of course), the regular rexpression
engine is quite good and well-tested. I'll take a look into it later.

Anyway, nice patch, and if Str.reverse is fixed it'll certainly be applied.

Moritz

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

Re: Parrot 0.7.1 "Manu Aloha" released

[Patrick R. Michaud]

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.

Pm

[perl #58990] [TODO] Design new spec coverage mechanism

[via RT]

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


We need a way to measure the extent to which Parrot's test suite covers
the Parrot specification.  Since the specification is expressed in words
rather than code, a quantitative measurement of the "spec coverage" is
unlikely.  However, a visual representation of that coverage is possible
and desirable.  For example, HTML versions of the Parrot design
documents might carry annotations which indicate which tests exercise
the code described in particular paragraphs in the PDDs.

The objective of this RT is to develop a specification for a new spec
coverage mechanism.   The specification, like other PDDs, should be
written in Perl 5 POD.  This specification should define key terms; it
should not assume, for example, that everyone knows what a 'smartlink'
is.  It should describe the graphic appearance of the spec coverage
mechanism and specify what functionality (e.g., 'mouse over') the
functionality will have.  While it should draw upon "prior art" where
appropriate, it should not depend on a reader being previously familiar
with, e.g., the Pugs implementation.

The specification should also include a plan for testing the spec
coverage mechanism, including both unit and functionality tests.  A
testing plan, in broad outline, should exist before any code is written.
The code should be written in easily maintainable Perl 5 and documented
in Perl 5 POD.

Note:  While the spec coverage mechanism will ultimately have to be
written in Perl 5 POD, we should consider doing some early drafts on the
Parrot wiki.  Those readers of the list who want to work on this project
should speak up as to whether this is a good way to proceed.

[perl #58742] [TODO] Marker for RTs re SmartLinks

[James Keenan via RT]

On Wed Sep 17 05:30:18 2008, [EMAIL PROTECTED] wrote:

> > 
> > 4.  I will then open up a new RT of the [RFC] class.  This ticket will
> > call for development of a specification of a way to visually display the
> > extent to which Parrot's tests cover the specification.  I'll be quoting
> > from particle's post -- but I'm sure there will be additional questions
> > for Jerry.  The spec will call for a way to test whatever code we
> > develop to meet the spec.  So, rather than asking people to rush out to
> > write code, we'll focus first on determining what we want and need.
> > 
> 
> Still TODO.

Done.  So this RT is now resolved and superseded by # 58990.

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

[John M. Dlugosz]

Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:

I have come to understand that this is an available possibility, yes.
That doesn't mean I like it. :)

My complaint could be pithily summarized as "those are _my_,
attributes, why can't I write to them?"

// Carl

  
If the accessor were implemented to do something more interesting than 
just assign to the private location, then having some code call the 
accessor and other code access the private location directly with the 
same syntax would be confusing.


For untyped variables, it would be difficult to determine whether 
something is a method call or an attribute on a type that I'm in the 
body of.  Everything would have to be public methods, with a run-time 
check on the scope of the caller to see if it were allowed.   Having a 
different syntax for private access simplifies things.


I'm wondering if the strange wording concerning
 has $x;
with no twigal is meant to take care of this case.  But I don't 
understand what he meant in the Synopses, though I've asked about it 
repeatedly on this list and other places, so I largely ignore that case.


It says something about making $x available as an alias in the lexical 
scope.  In context of what you are asking, maybe that's what it is for.


--John

Re: How to define a new value type?

[John M. Dlugosz]

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

Reading the description there I wonder how this is supposed to work.
I don't think S29 is in any shape as a serious design specification.  
Maybe you should not design it that way.  Maybe the left-hand-side is 
"as ref" so it can change the identity of the object it is called on.


our Str multi method substr (Str $string is ref: StrPos $start, Int 
$length)

is rw is export
{

... compute result in a new variable
$string = $result;  # ta-da!
... and what am I supposed to return?  A Str-like object that is a proxy 
to just

the changed substring?
}


As for your other comments in general, I think S29 is NOT in any shape 
as a gospel, and going over the (very preliminary) design is a necessary 
task.


--John

Re: How to define a new value type?

[John M. Dlugosz]

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

Sorry, I don't understand why you say 'no' and then explain that the
resulting new string is stored in the container. The only container
that could be affected by this is $string in the example. The way for
a method to get access to the container is by declaring a parameter
as rw. Note that this brings the discussion back to the point how rw
is handled in dispatch and if an anonymous container is autovivified
for a naked value.

For "rw" yes, for "ref" no.




Did you mean the 'no' as answer to the question if
the identity of the string--i.e. its pointer--is preserved? This would
violate the immutability assertion of string values.

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.


But off the cuff, I think it is safe to say that 'ref' parameters are 
guaranteed to have the same container that the caller sees, and 'copy' 
parameters are guaranteed not to.  default (read-only) passing may or 
may not at the implementation's whim, but you won't change it so it 
doesn't matter.  'rw' may allow the value to change before binding; 
'ref' never permits that.



--John

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

[Damian Conway]

Larry wrote:


You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.  


When thinking about this, it's also important to remember that, in Perl 6, not 
everything with a sigil is automatically writeable. For example:


constant $answer = 42;
$answer = 99;  # Kaboom!

sub foo( $bar ) {
$bar = 42  # Biff!!
}

$baz := 86;
$baz++;# Zowie!!!


Likewise a $.foo attribute defaults to read-only,
whereas a $!foo attribute defaults to read-write.

Damian

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

[Chris Davaz]

Ok, here it is without the change to "split on a string", and the test
passes. 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.


On Thu, Sep 18, 2008 at 1:57 AM, Moritz Lenz <[EMAIL PROTECTED]>wrote:

> Chris Davaz (via RT) wrote:
> > # New Ticket Created by  "Chris Davaz"
> > # Please include the string:  [perl #58970]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt3/Ticket/Display.html?id=58970 >
> >
> >
> > I say "initial" because it didn't pass one of my tests.
>
> More importantly it introduces a regression in t/spec/S29-list/reverse.t
> (Str.reverse is implemented in terms of split-into-characters -> list
> reverse -> join; the split failed with your patch, thus causing a test
> failure in 'make spectest_regression')
>
> > This might be due to
> > regular expressions not being fully implemented, so if this is the case
> > please let me know.
>
> That's unlikely (but not impossible, of course), the regular rexpression
> engine is quite good and well-tested. I'll take a look into it later.
>
> Anyway, nice patch, and if Str.reverse is fixed it'll certainly be applied.
>
> Moritz
>
> --
> 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,50 @@
 .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:
+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