Parrot 0.7.1 "Manu Aloha" released

[Patrick R. Michaud]

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.

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!

[perl #58946] [META] October 2008 release

[Patrick R. Michaud (via RT)]

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


This metaticket is for issues related to the October 2008 release of
Parrot, planned for October 21st 2008. The release manager will be
Jerry Gay.

Pm

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

[Patrick R. Michaud]

On Tue, Sep 16, 2008 at 11:45:17PM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
> What's TAKE?
 TAKE is like CONTROL_RETURN except that it signals that we expect
 execution to continue after the point of the TAKE.  It's quite
 similar to a .yield operation for coroutines.
>>> Would CONTROL_YIELD make more sense? I would have known what yield meant.
>>
>> It might be a bit misleading, because it doesn't actually correspond
>> to a .yield (and thus I can envision CONTROL_YIELD as yet another
>> exception type).  
>
> Eventually we'll need to stop defining exception types as a global enum,  
> and let individual languages define their own. EXCEPTION_TAKE really  
> doesn't make sense for anything other than Perl 6. Not today, but 
> someday.

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.  :-)

In particular, having gather/take readily available may make it 
easier to implement many internal functions and libraries, even
if gather/take itself isn't directly exposed at the HLL layer.
Similar arguments probably hold for other "core" features of Parrot.

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.

Pm

Re: ExceptionHandler enhancement proposal

[Bob Rogers]

   From: Allison Randal <[EMAIL PROTECTED]>
   Date: Tue, 16 Sep 2008 22:51:29 +0200

   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.

   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.

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: How to define a new value type?

[John M. Dlugosz]

Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:


For an Object to be a value, it means that if you build an object with
the same "value", it will be seen as the same "value" that some other
object with this value.
  
Perl 6 formalizes this by defining a "value type" as one whose identity 
is keyed to its value.  Multiple physical copies in memory (or copies 
without memory like numbers in registers) will test as identity-equvilent.




A sane requirement for this to happen is that "value" objects are
read-only, which is something pretty straight-forward.

The thing is that, for a "value" object, there isn't any difference in
saying:

  my $a := 3;

or

  my $a := 3.clone();

Because the number '3' is a value, and you usually doesn't expect a
value to change its value at a distance, that's why Int is Immutable.

  
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.

Re: How to define a new value type?

[John M. Dlugosz]

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


I think that mutating methods of immutable value types just have
to modify the identity. The problem is how that relates to references.
Take e.g. the Str type

   my $s = 'abc'; # $s points to 'abc'
   $s.reverse;

where the reverse method returns a new string that somehow has to
find its way into $s. That is, the method call sequence has to be
different for object types and value types. The start is identical:



Don't do that.   Changing the identity of the object will mean that 
other containers pointing to the same copy will change, but other 
containers pointing to another physical copy (but the same id) will not. 



Well, or the language is explicit about the capture of the new
value. Is this meant with

   $s.=reverse; # means $s = $s.reverse




Yes.  Define .reverse to return a new object, and use .= if you want it 
to go back into the same container.  I suppose that seeing .= will make 
it easy for the compiler to optimize, if the object is not shared it can 
reuse the structure.


--John

Re: How to define a new value type?

[John M. Dlugosz]

Stéphane Payrard cognominal-at-gmail.com |Perl 6| wrote:

I don't understand how = differs with that semantic from :=
I would expect that = would make a copy (clone?) of the object.
For a mutable object, I don't know if that copy should be immediate or deffered
by a mechanism of copy on write. Probably that behavior could depend on a
trait of the class that implements to be copied object.

  


Not the best illustration, but the only one I have prepared so far:


This shows $x = $y;.

The use of := (binding) would affect the leftmost column. 


  my $z := $y;

would have $z's symbol table entry point to the same Item as $y, namely 
#8CD9.


Assignment (=) does not clone or copy the object.  In the illustration, 
note that both Items refer to the same Dog (#A829) after assignment.  
With reference assignment semantics, if you want a copy or clone, you 
make one as an explicit step.  Hence the existence of methods like 
deepcopy in the base Object of languages with that feature.


The copy-on-write behavior you suggest is what Perl 5 does to make 
operator overloading appear to have value semantics.  But Perl 6 does 
not describe this mechanism in any way.  Instead, "value types" are 
immutable so it doesn't matter that the object is not cloned.


--John

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

[James Keenan via RT]

On Tue Sep 16 15:45:47 2008, [EMAIL PROTECTED] wrote:
> 
> Okay, here's what I propose we do:
> 
> 1.  I will examine the 12 unresolved tickets to see if there are any
> which will not be automatically closable once my patch is applied.
> 

Examination complete.

> 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/.
>

Patch refined in nosmartlink branch.  Am waiting for release before
merging to trunk.

 
> 3.  I will resolve/reject the unresolved tickets.
> 

Done.

> 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.
> 

TODO

[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests

[James Keenan via RT]

As the discussion evolved in RT 58742, the consensus was that the
current smartlink functionality in Parrot is not working and that a
fresh approach must be taken.  So we're deleting the smartlink-related
files (or, at the very least, those outside of the languages/
directory).  That means we can this ticket.

szbalint++ for moving the discussion forward.

Thank you very much.
kid51

[perl #46899] [TODO] [Perl] Integrate smartlink info and emit html in smartlinks.pl

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46801] [TODO] [Perl] Test tools/util/smartlinks.pl

[James Keenan via RT]

Rejected, as we're deleting this file.

[perl #46799] [TODO] [Perl] Perform end-to-end testing of SmartLinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46797] [TODO] [Perl] Add more tests of SmartLinkServer to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46795] [TODO] [Perl] Add more tests of TestInfo to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46793] [TODO] [Perl] Add more tests of Test to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46791] [TODO] [Perl] Add more tests of SpecFiles to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46789] [TODO] [Perl] Add many more tests of SpecFiles->files to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46787] [TODO] [Perl] Add tests of PodFile->tree to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the file proposed for expansion.

[perl #46785] [TODO] [Perl] Add more File-related tests to the smartlinks tests

[James Keenan via RT]

Rejected, as we're deleting the test file which the OP calls for expanding.

[perl #46857] [TODO] [Pir] Fix smartlinks in exporter PMC tests once speced

[James Keenan via RT]

Rejected, as we're deleting the test file which the OP calls for expanding.

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

[James Keenan via RT]

On Tue Sep 16 06:50:26 2008, particle wrote:
> >
> parrot needs a way for us to measure spec coverage in our test suite.
> i started the current smartlinks code as an experiment in using moose,
> and as a reaction to the mess of smartlink code that's in the pugs
> repo. however, i'm not married to the code, so rip it out if you
> like--i never completed it, anyway.
> 
>...
> 
> i'd *love* to see smartlinks working in parrot. one of the big
> problems in the parrot test suite is our lack of ability to measure
> the test coverage of both code and spec. although smartlinks likely
> won't offer us solid quantitative metrics, it will provide important
> visual qualitative measures.

Okay, here's what I propose we do:

1.  I will examine the 12 unresolved tickets to see if there are any
which will not be automatically closable once my patch is applied.

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/.

3.  I will resolve/reject the unresolved tickets.

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.

Thank you very much.

kid51

[perl #46651] [TODO] [C] Make a better interface for hash creation

[James Keenan via RT]

Marked as rejected.

Re: [perl #46651] [TODO] [C] Make a better interface for hash creation

[Allison Randal]

Christoph Otto via RT wrote:

On Mon Oct 22 07:01:59 2007, pcoch wrote:

In src/pmc/hash.pmc:thaw() there is the todo item:

/* TODO make a better interface for hash creation

... do this.


Where do we want to go with this?


Ax the ticket. Vague plans for future change aren't useful.

Allison

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

[chromatic]

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

Re: [perl #58918] [BUG] Can't use a subdir class twice

[Nicholas Clark]

On Tue, Sep 16, 2008 at 11:55:25AM -0700, P N wrote:
> HI
> 
> 
> 
> sorry to bug you - but I'm getting this message from you and others quite 
> often.
> 
> how would I un-subsscribe to this. If you knew how, please let me know.

Mailing [EMAIL PROTECTED] should work.

(assuming that that's the list you're subscribed to, rather than some list that
re-sends its content, and that the address that list server has for your
subscription is not the same as the address your outgoing mail comes from.
If this isn't right, you can mail [EMAIL PROTECTED] to reach a
human who can access the list database - I'm just a mere mortal without this
super-power)

These addresses are given in the full headers of the messages to the list,
which I guess your mail client doesn't show you. If you're able to get it to
show full headers you can confirm the list you're subscribed to, and get the
correct unsubscribe address.

Nicholas Clark

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

[Allison Randal]

Vasily Chekalkin wrote:


And another question. Should all lvalue occurences of PMC_*_val(SELF) be 
replaced with VTABLE_set_*_native? (Except for VTABLE method 
implementation of cause)


In general, yes. You'll have to check each PMC to see if they have the 
appropriate VTABLE_set_*(_native) vtable function defined.


(Ultimately, the storage for these PMCs should all be changed to ATTRs 
and the accessors to GET_ATTR_* and SET_ATTR_*.)


Allison

Re: [perl #58934] [CAGE] 'make fulltest' says "PASS" at the end, although some tests failed

[jerry gay]

On Tue, Sep 16, 2008 at 12:27 PM, via RT Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Moritz Lenz
> # Please include the string:  [perl #58934]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58934 >
>
>
> 'make fulltest' runs several chunks of tests, and does not show a final
> summary. So although some tests in some chunks fail, the last thing that
> the tester sees is something along these lines:
>
> ===(  35
> )==All tests
> successful.
> Files=10, Tests=108, 29 wallclock secs ( 0.04 usr  0.02 sys + 19.55 cusr
>  1.44 csys = 21.05 CPU)
> Result: PASS
> make[1]: Leaving directory `/home/moritz/src/parrot'
>
> If only the last chunk succeeded.
>
> This is very misleading, and probably dangerous.
>
> At the very least it should say something like "WARNING: not all tests
> were successful, scroll up to find out which failed".
> This could be done by collecting the return values from the various
> 'make test*' calls.
>
> Even better would be real summary at the end listing the failed tests.
>
> (Observed with perl-5.10.0 and Test::Harness 3.11, parrot as of
> shortly-before 0.7.1)
>
> Moritz
> --
> Moritz Lenz
> http://moritz.faui2k3.org/ |  http://perl-6.de/
>

parrot's fulltest runs the harness multiple times without a very clear
distinction. as i understand, this behavior can now be changed, as we
require T::H 3. the fulltest target must be modified to report the
results from each harness run together at the end, rather than
seperately after each harness run.

~jerry

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

[NotFound]

> 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.

-- 
Salu2

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:

On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote:

+CONTROL_TAKE
 } exception_type_enum;

Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN.

What's TAKE?

TAKE is like CONTROL_RETURN except that it signals that we expect
execution to continue after the point of the TAKE.  It's quite
similar to a .yield operation for coroutines.

Would CONTROL_YIELD make more sense? I would have known what yield meant.


It might be a bit misleading, because it doesn't actually correspond
to a .yield (and thus I can envision CONTROL_YIELD as yet another
exception type).  I'm still brainstorming ways to get the gather/take
semantics we need by using Parrot's .yield, but so far I haven't 
come up with a good way to do it.


Eventually we'll need to stop defining exception types as a global enum, 
and let individual languages define their own. EXCEPTION_TAKE really 
doesn't make sense for anything other than Perl 6. Not today, but someday.


Allison

[perl #58934] [CAGE] 'make fulltest' says "PASS" at the end, although some tests failed

[via RT]

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


'make fulltest' runs several chunks of tests, and does not show a final
summary. So although some tests in some chunks fail, the last thing that
the tester sees is something along these lines:

===(  35
)==All tests
successful.
Files=10, Tests=108, 29 wallclock secs ( 0.04 usr  0.02 sys + 19.55 cusr
 1.44 csys = 21.05 CPU)
Result: PASS
make[1]: Leaving directory `/home/moritz/src/parrot'

If only the last chunk succeeded.

This is very misleading, and probably dangerous.

At the very least it should say something like "WARNING: not all tests
were successful, scroll up to find out which failed".
This could be done by collecting the return values from the various
'make test*' calls.

Even better would be real summary at the end listing the failed tests.

(Observed with perl-5.10.0 and Test::Harness 3.11, parrot as of
shortly-before 0.7.1)

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

Re: {SPAM} Re: How to define a new value type?

[Daniel Ruoso]

Ter, 2008-09-16 às 18:04 +0200, TSa escreveu:
> I think that mutating methods of immutable value types just have
> to modify the identity. The problem is how that relates to references.
> Take e.g. the Str type

I really think we are looking at this problem from the wrong
perspective.

For an Object to be a value, it means that if you build an object with
the same "value", it will be seen as the same "value" that some other
object with this value.

A sane requirement for this to happen is that "value" objects are
read-only, which is something pretty straight-forward.

The thing is that, for a "value" object, there isn't any difference in
saying:

  my $a := 3;

or

  my $a := 3.clone();

Because the number '3' is a value, and you usually doesn't expect a
value to change its value at a distance, that's why Int is Immutable.

daniel

Re: [perl #58918] [BUG] Can't use a subdir class twice

[P N]

HI



sorry to bug you - but I'm getting this message from you and others quite often.

how would I un-subsscribe to this. If you knew how, please let me know.

thanks



Peter.

[EMAIL PROTECTED]


Peter.

[EMAIL PROTECTED]

--- On Tue, 9/16/08, Stephen Simmons <[EMAIL PROTECTED]> wrote:
From: Stephen Simmons <[EMAIL PROTECTED]>
Subject: [perl #58918] [BUG] Can't use a subdir class twice
To: [EMAIL PROTECTED]
Date: Tuesday, September 16, 2008, 7:36 AM

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


In r31096, use allows a program to use module A and module B, and allows
module B to use module A, when module A defines a method as long as all
three files are in the same directory.  However, when you try and put module
A and module B in the Lib subdirectory and use them as Lib::A and Lib::B,
then rakudo complains with:
A method named 'test' already exists in class 'A'. It may have
been supplied
by a role.
current instr.: 'parrot;PCT::HLLCompiler;evalpmc' pc 10631758 ((unknown
file):-1)
perl6(18090) malloc: *** error for object 0x315ad60: double free
*** set a breakpoint in malloc_error_break to debug
Segmentation fault

The attached file illustrates the problem.

System info:
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

Stephen Simmons



  

Re: [perl #58794] [PATCH] remove the obsolete .past search in try_bytecode_extensions

[Allison Randal]

Reini Urban (via RT) wrote:

Old: Guess extensions, so that the user can drop the extensions
leaving it up to the build process/install whether or not
a .pbc, .pasm, .past or a .pir file is used.

New: Search only for .pbc, .pasm, and .pir in that order.

The .past file-extension is *long* deprecated said particle on #parrot.


Thanks, approved for application in trunk.

Allison

Re: [svn:parrot] r30941 - branches/pdd27mmd/src

[Allison Randal]

NotFound wrote:


By the way, as mentioned in other thread there is a problem with plain
%s in parrot printf-alike functions. It does not handle well a NULL c
string. This must be fixed. And before, given the current
implementation, the behavior of string_make and his successor in the
strings pdd, when receiving a NULL c string must be documented and
implemented, or we risk to plague the code base with lots of more
workarounds.


This should be submitted as a separate ticket with example code/error 
messages.


Allison

Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19

[Allison Randal]

Klaas-Jan Stol wrote:

Allison:

I made the following changes in pirc/new:

.arg -> .set_arg
.result -> .get_result
.return -> .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return -> .set_return (in long-style returning : .begin/end_return
.yield -> .set_yield ( in long-style yielding : .begin/end_yield)

From your answers in your previous reply I deduce you support such changes.
Can you reconfirm, then I'll make the appropriate changes in  PDD19.


Thumbs up, thanks!

Allison

[perl #58936] [TODO]

[[EMAIL PROTECTED] (via RT)]

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


With Rakudo 0.7.0-devel r31065 inheritance works as in this
single file:

class Dog {
has $.name is rw;
method bark() {
say "$.name says Woof!";
}
}

class Pug is Dog {
method set_name( $n ) {
$.name = $n;
}
}

my $pot = Pug.new();
$pot.set_name( 'Spot' );
$pot.bark();

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'.

On 2008-09-16 in #perl6 moritz explains that 'use' happens
(erroneously) at run time whereas it should happen at
compile time, and gives a
workaround 'BEGIN { use Dog; };' that works.

Synopsis 11 topic "Runtime Importation" contrasts 'use' and
'require' in terms of time. This request is to obviate the
workaround.

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

[via RT]

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


It prints "0\n" instead of the expected "i\n"

-- 
cognominal stef

[perl #58922] .perl for self-referent structures

[Carl Mäsak]

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


Calling .perl on a self-referent structure makes Rakudo r31152 hang.

$ ./perl6 -e 'my @a = (1); @a[0] := @a; @a.perl'

 pmichaud: what about @a[0] := @a ?
 masak:  I don't know about that one.  :-)
[...]
 :)
[...]
 part of me thinks that ends up with a self-referential structure
 I hope so
 that seems to be what's happening in at least one case in
Rakudo right now
 question is, should .perl be able to handle that, and if so, how?
 masak: it should
 perhaps it should emit something like 'do { my @x = (...);
@x[0] := @x; @x }'
* masak submits rakudobug

Re: [perl #39313] [TODO] or [BUG] improve PMC compiler

[Allison Randal]

Klaas-Jan Stol wrote:

This ticket doesn't seem to be closeable as is.Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?


The goal of the ticket should be for pmc2c.pl to entirely parse the
input PMC files. Either passing through uncooked C, or doing
transformations. Silently dropping code on the floor is not
acceptable.


Pmc2c is just a series of regular expressions. It looks for specific 
patterns, and if it finds them, builds relevant C code out of them.


It has no ability to check for arbitrary syntax that *doesn't* match a 
pattern. It's a preprocessor (macro substitution), not a language parser.


What could be done is have it dump anything leftover after the 
extraction into the resulting C file. Then you'd get a C error on 
compilation.




wouldn't a PGE-based compiler be helpful?


Yes, certainly desirable, but we're not shooting for that level of 
bootstrapping in the 1.0 release. When we eliminate all dependencies on 
Perl, we'll move over to a PGE-based compiler, and keep the generated C 
code checked into the repository like we keep the generated flex/bison 
files checked in.


Allison

Re: [perl #58938] [BUG] src/string.c:2241: failed assertion '(s)->encoding'

[Reini Urban]

2008/9/16 via RT Reini Urban <[EMAIL PROTECTED]>:
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58938 >

If you don't spot the error immediately, here's a hint:
> #5  0x639518e0 in pmc_type () from /usr/bin/cygparrot0_7_0.dll

wrong lib. caused by what?
the lib should be called
/usr/src/parrot/parrot-svn/blib/lib/libparrot.dll but an installed
only config lib and /bin/parrot points to this new name: cygparrot0_7_0.dll

So it's related to the RT#39742 installed-conflict bug, but
I keep this ticket open for this subtle problem until I find the
reason for the mismatch after loadlib.

> Since a few days loadlib initialization causes an
> src/string.c:2241: failed assertion '(s)->encoding'
>
> See http://nopaste.snit.ch/14072
> gdb backtrace:
>
> src/string.c:2241: failed assertion '(s)->encoding'
> $ cat encoding-bug.pir
> loadlib 'rotest'
>
> $ gdb ./parrot encoding-bug.pir
>
> (gdb) s
>
> Breakpoint 7, string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793)
>at src/string.c:2241
> 2241saneify_string(s);
> (gdb) p *s
> $1 = {cache = {_b = {_bufstart = 0x69205def, _buflen = 6}, _ptrs = {
>  _struct_val = 0x69205def, _pmc_val = 0x6}, _i = {_int_val = 1763728879,
>  _int_val2 = 6}, _num_val = 1.3603372593483627e-313,
>_string_val = 0x69205def}, flags = 405760, strstart = 0x69205def "ROTest",
>  bufused = 6, strlen = 6, hashval = 0, encoding = 0x0, charset = 0x0}
> (gdb) bt
> #0  string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793) at 
> src/string.c:2241
> #1  0x66fa9aa3 in key_hash_STRING (interp=0x1ef2328, s=0x1f41278, seed=3793)
>at src/hash.c:153
> #2  0x66faaa5e in parrot_hash_get_bucket (interp=0x1ef2328, hash=0x1f6ce88,
>key=0x1f41278) at src/hash.c:1093
> #3  0x66faaaef in parrot_hash_get (interp=0x1ef2328, hash=0x1f6ce88,
>key=0x1f41278) at src/hash.c:1123
> #4  0x67166491 in Parrot_NameSpace_get_pointer_keyed_str (interp=0x1ef2328,
>pmc=0x1f67d48, key=0x1f41278) at ./src/pmc/namespace.pmc:434
> #5  0x639518e0 in pmc_type () from /usr/bin/cygparrot0_7_0.dll
> #6  0x63951971 in pmc_register () from /usr/bin/cygparrot0_7_0.dll
> #7  0x69203d6a in Parrot_lib_rotest_load (interp=0x1ef2328) at ./rotest.c:1166
> #8  0x66f9c9ee in Parrot_init_lib (interp=0x1ef2328,
>load_func=0x69203d20 , init_func=0)
>at src/dynext.c:317
> #9  0x66f9cb21 in run_init_lib (interp=0x1ef2328, handle=0x6920,
>lib_name=0x20e4b78, wo_ext=0x20e4b78) at src/dynext.c:384
> #10 0x66f9d0d9 in Parrot_load_lib (interp=0x1ef2328, lib=0x1f412a0,
>initializer_unused=0x0) at src/dynext.c:583
> #11 0x671a7f46 in do_loadlib (interp=0x1ef2328, lib=0x21066f8 "'rotest'")
>at compilers/imcc/imcc.y:602
> #12 0x671a8d0b in yyparse (yyscanner=0x20f2078, interp=0x1ef2328)
>at compilers/imcc/imcc.y:737
> #13 0x671b5281 in compile_to_bytecode (interp=0x1ef2328,
>sourcefile=0xc3cce4 "encoding-bug.pir", output_file=0x0)
>at compilers/imcc/main.c:955
> #14 0x671b562c in imcc_run (interp=0x1ef2328,
>sourcefile=0xc3cce4 "encoding-bug.pir", argc=1, argv=0x1ef213c)
>at compilers/imcc/main.c:1058
> #15 0x00401120 in main (argc=1, argv=0x1ef213c) at src/main.c:61
> (gdb)
>
>
>
>
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>



-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Re: ExceptionHandler enhancement proposal

[Allison Randal]

Stephen Weeks wrote:

ExceptionHandler currently has a can_handle method that checks whether
the EH has been disabled or not.  I propose adding some attributes to
store the minimum severity the EH will handle and the list of exception
types the EH will handle, methods to set and get these properties, and
extend can_handle to check the exception against these properties.


Yes, this was spec'd but not yet implemented, and can be implemented 
now. ('can_handle' was intended to be expanded for this.)



Once this is in place, I understand we can remove the "disable exception
handler" functionality currently in place and replace it with setting
handled types appropriately.


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.)



Questions that have been raised about this proposal on IRC include:

* Minimum severity, range of severities, list of severities?


Minimum and maximum (which define a range if both are set). Let's skip 
selective lists ("I'll handle severity 2, 8, and 42" is less useful).



* List of types, or single type?
- Note that you could create multiple EHs that refer to the same
  label or sub that handle different exception types.


A list of types. Ultimately exception types will likely be more than 
just integer types, but the integer types will do for now.



Also, the 'can_handle' method can be overloaded to check *any* attribute 
of the exception to decide if that handler can handle it. We may want to 
canonize this by allowing Parrot's ExceptionHandler PMC to store a sub 
object that is run by 'can_handle' on the exception to determine if it's 
appropriate.



Any proposals on naming or other API considerations?


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.



Any other thoughts or comments?


Make it so, Mr. Crusher. :)

Allison

[perl #58938] [BUG] src/string.c:2241: failed assertion '(s)->encoding'

[via RT]

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


Since a few days loadlib initialization causes an
src/string.c:2241: failed assertion '(s)->encoding'

See http://nopaste.snit.ch/14072
gdb backtrace:

src/string.c:2241: failed assertion '(s)->encoding'
$ cat encoding-bug.pir
loadlib 'rotest'

$ gdb ./parrot encoding-bug.pir

(gdb) s

Breakpoint 7, string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793)
at src/string.c:2241
2241saneify_string(s);
(gdb) p *s
$1 = {cache = {_b = {_bufstart = 0x69205def, _buflen = 6}, _ptrs = {
  _struct_val = 0x69205def, _pmc_val = 0x6}, _i = {_int_val = 1763728879,
  _int_val2 = 6}, _num_val = 1.3603372593483627e-313,
_string_val = 0x69205def}, flags = 405760, strstart = 0x69205def "ROTest",
  bufused = 6, strlen = 6, hashval = 0, encoding = 0x0, charset = 0x0}
(gdb) bt
#0  string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793) at src/string.c:2241
#1  0x66fa9aa3 in key_hash_STRING (interp=0x1ef2328, s=0x1f41278, seed=3793)
at src/hash.c:153
#2  0x66faaa5e in parrot_hash_get_bucket (interp=0x1ef2328, hash=0x1f6ce88,
key=0x1f41278) at src/hash.c:1093
#3  0x66faaaef in parrot_hash_get (interp=0x1ef2328, hash=0x1f6ce88,
key=0x1f41278) at src/hash.c:1123
#4  0x67166491 in Parrot_NameSpace_get_pointer_keyed_str (interp=0x1ef2328,
pmc=0x1f67d48, key=0x1f41278) at ./src/pmc/namespace.pmc:434
#5  0x639518e0 in pmc_type () from /usr/bin/cygparrot0_7_0.dll
#6  0x63951971 in pmc_register () from /usr/bin/cygparrot0_7_0.dll
#7  0x69203d6a in Parrot_lib_rotest_load (interp=0x1ef2328) at ./rotest.c:1166
#8  0x66f9c9ee in Parrot_init_lib (interp=0x1ef2328,
load_func=0x69203d20 , init_func=0)
at src/dynext.c:317
#9  0x66f9cb21 in run_init_lib (interp=0x1ef2328, handle=0x6920,
lib_name=0x20e4b78, wo_ext=0x20e4b78) at src/dynext.c:384
#10 0x66f9d0d9 in Parrot_load_lib (interp=0x1ef2328, lib=0x1f412a0,
initializer_unused=0x0) at src/dynext.c:583
#11 0x671a7f46 in do_loadlib (interp=0x1ef2328, lib=0x21066f8 "'rotest'")
at compilers/imcc/imcc.y:602
#12 0x671a8d0b in yyparse (yyscanner=0x20f2078, interp=0x1ef2328)
at compilers/imcc/imcc.y:737
#13 0x671b5281 in compile_to_bytecode (interp=0x1ef2328,
sourcefile=0xc3cce4 "encoding-bug.pir", output_file=0x0)
at compilers/imcc/main.c:955
#14 0x671b562c in imcc_run (interp=0x1ef2328,
sourcefile=0xc3cce4 "encoding-bug.pir", argc=1, argv=0x1ef213c)
at compilers/imcc/main.c:1058
#15 0x00401120 in main (argc=1, argv=0x1ef213c) at src/main.c:61
(gdb)




-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Re: throw oddities in pdd23

[Patrick R. Michaud]

On Tue, Sep 16, 2008 at 10:14:24PM +0200, Allison Randal wrote:
>
> Okay, PDD cleaned up. The code to directly support throwing any  
> arbitrary type would require significant circumlocution (read:  
> inefficient, difficult to maintain), so it's not desirable. 
> [...]
> But, an individual HLL can store any arbitrary PMC value as the payload  
> of an exception object, and act as if it had thrown an arbitrary PMC as  
> an exception.

Works for me, thanks.  Now I'm just eagerly awaiting comments on
Stephen Weeks' proposals.  :-)

Pm

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

[Allison Randal]

Christoph Otto (via RT) wrote:


I was looking at #45357 ([TODO] Which exception should be thrown with register 
overflow?) and found that Parrot doesn't like subs with more than 205 params. 
  This seems like a perfectly reasonable limit, but perhaps the behavior could 
be more user-friendly.*  Maybe an EXCEPTION_ERR_OVERFLOW should be thrown here 
instead?


Using the attached patch to reproduce:
$ perl mktoomanyargs.pl>toomanyargs.pir && ./parrot toomanyargs.pir
Segmentation fault (core dumped)


*On the other hand, we may choose to be overtly hostile to users who do things 
like call subs with 206 parameters.  It's a design decision.


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.


Allison

Re: [perl #58886] [BUG] :named argument handling in PIR

[Allison Randal]

Will Coleda (via RT) wrote:
[...]


I would expect one of the following things to happen here, either:

- an error is generated when test2 is parsed because there is no name
for the named parameter, or
- test2's blarg .param should default to being named 'blarg', so both
calls should work identically.

Even more confusing, this code:


Yes, we need better error checking and better error reporting in named 
argument handling. We need a general invocation refactor, but can do it 
in small stages.


Let's go with defaulting to the same name as the .param on the bare :named.

Allison

Re: throw oddities in pdd23

[Allison Randal]

Patrick R. Michaud wrote:

PDD23:67 has:

: =item B>
: 
: Throw an exception consisting of the given I PMC.  Active exception

: handlers (if any) will be invoked with I as the only parameter.
: 
: 
: =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. Active exception handlers (if any) will be
: invoked with I and the given continuation as parameters.

This looks weird in a couple of respects.  The second C 
opcode shows I as an optional parameter, which 
would seem to be in conflict with the first form (i.e., they

end up being identical if I is omitted).

Next, reading the above makes it look as though exception handlers
can sometimes be invoked with a single parameter (the exception)
and sometimes with two parameters (the exception and a continuation).
Perhaps it would be better to have a consistent calling interface?
(I do suppose we could say that the second parameter is always optional.)

I suspect much of the confusion comes from when C was
(apparently) eliminated in favor of a single C opcode, 
but pdd23 wasn't made internally consistent.


Yes, C and C were collapsed into one opcode, and left 
some editing junk behind.


I just changed it to one entry for C.


Also, note that the single-argument C opcode is currently
doing more than simply cause exception handlers to be invoked -- 
it's also takes a resume continuation and stores it in the
I PMC itself (src/ops/core.ops:817).  This would seem 
to be in conflict with the next sentence at pdd23:80 :


: Any type of PMC can be thrown as an exception.  


Clearly we cannot use the single-argument C on a PMC that
doesn't have a "resume" attribute for us to store the
resume continuation.

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).  


Alternatively, we could say that C only places a resume
continuation into PMCs that "does exception", but somehow I
find this less desirable than the above approach.


Okay, PDD cleaned up. The code to directly support throwing any 
arbitrary type would require significant circumlocution (read: 
inefficient, difficult to maintain), so it's not desirable. It's not 
just a matter of removing the return continuation from the exception 
object, we'd have to remove all metadata from the exception object 
(stacktrace, payload, handler iterator, type and severity information), 
and either pass all that information as arguments throughout the system 
(expensive and error-prone) or store it as global state information 
(error-prone, and bad for a clean implementation of concurrency).


But, an individual HLL can store any arbitrary PMC value as the payload 
of an exception object, and act as if it had thrown an arbitrary PMC as 
an exception.


Allison

[svn:parrot-pdd] r31186 - trunk/docs/pdds

[allison]

Author: allison
Date: Tue Sep 16 13:12:27 2008
New Revision: 31186

Modified:
   trunk/docs/pdds/pdd23_exceptions.pod

Log:
[pdd] Clarifying the description of the 'throw' opcode, and the necessary
interface of thrown exceptions.


Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podTue Sep 16 13:12:27 2008
@@ -64,27 +64,17 @@
 Pop the most recently pushed exception handler off the exception handler
 stack.
 
-=item B>
-
-Throw an exception consisting of the given I PMC.  Active exception
-handlers (if any) will be invoked with I as the only parameter.
-
-
 =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. Active exception handlers (if any) will be
-invoked with I and the given continuation as parameters.
-
-Any type of PMC can be thrown as an exception.  However, if there's any chance
-of cross-language calls -- and in a Parrot environment, cross-language
-operations are kind of the point -- then you should be prepared to catch
-exception classes you would never have thrown yourself.
-
-That said, it is recommended that any thrown PMC that can possibly escape your
-private sandbox should meet the minimal interface requirements of the
-C class, described below.
+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 continuation which is stored in the exception object.

Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror

[Andy Dougherty]

I think you've gone about this in the right way, but need to handle the 
various cases a bit more broadly.  Specifically, you can't assume that 
everyone has strerror() at all (Solaris 8 doesn't, for example) nor that 
everyone who uses int strerror_r() will also define either _XOPEN_SOURCE 
or _POSIX_C_SOURCE (NetBSD doesn't, for example).

I think perhaps a structure like the following might work:

#if defined(HAS_STRERROR_R)
#  if defined(STRERROR_R_RETURNS_INT)
/* stuff using int strerror_r(); */
#  else
/* stuff using char *strerror_r() */
#else
/* stuff using plain strerror(). */
#endif

Currently, you are trying to guess which branch based on various #defines, 
but non-Linux systems will fall through to the wrong branch, and systems 
without strerror_r will fail completely.

Ideally, Configure.pl ought to figure which branch you need. Alas, it 
doesn't.  However, perl5's Configure does (at least for Unix systems), so 
you could just use it's results.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #58282] [BUG] "elsif defined $a { return $a}" fails

[Patrick R. Michaud]

On Tue, Sep 16, 2008 at 06:11:30PM +0200, Moritz Lenz wrote:
> Stephen Simmons (via RT) wrote:
> > sub max($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 }
> > }
> 
> in trunk, r31178 this gives the desired output (specifically '3 <-4>'),
> so I'll close this ticket.
> 
> (I suspect it was either a problem with defined() which was improved
> lately, or a parsing problem).

I think that C was being parsed as a listop instead of a named
unary, thus the C statement above was being parsed as

if defined( $a && defined($b) ) { ... }

Pm

[perl #58932] [DEPRECATED] P6object .new_class('Foo::Bar') will create ['Foo';'Bar']

[Patrick R. Michaud (via RT)]

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


Sometime after the 0.7.1 release, the P6object library will change
so that double-colons will be treated as separators in class names
passed to the 'new_class' method.

Consider the following code:

.local pmc p6meta
p6meta = get_hll_global 'P6metaclass'
p6meta.'new_class'('Foo::Bar')

Previously this would create a class ['Foo::Bar'] that
would look for its methods in the ['Foo::Bar'] namespace.
At some point after 0.7.1, the above will instead create
a class ['Foo';'Bar'] that looks for its methods in the ['Foo';'Bar']
namespace.

A method that is guaranteed to always bind the new class properly
to the namespace (even for other HLLs) is to pass the namespace 
itself as the first parameter to new_class:

.local pmc p6meta, classns
p6meta = get_hll_global 'P6metaclass'
classns = get_hll_global ['Foo';'Bar']
p6meta.'new_class'(classns)

If there is a case where the class name really needs to contain
double-colons, this can be done via a namespace parameter (above)
or by placing the name into an array of some sort:

classns = get_hll_global ['Foo::Bar']
p6meta.'new_class'(classns)

  or

$P0 = split(' ', 'Foo::Bar')
p6meta.'new_class'($P0)

Pm

Re: How to define a new value type?

[Moritz Lenz]

TSa wrote:
> HaloO,
> 
> Darren Duncan wrote:
>> If you are wanting to actually mutate a Dog in a user-visible way rather 
>> than deriving another Dog, then I don't think that calling Dog a value 
>> type is appropriate.
> 
> I think that mutating methods of immutable value types just have
> to modify the identity. The problem is how that relates to references.
> Take e.g. the Str type
> 
> my $s = 'abc'; # $s points to 'abc'
> $s.reverse;

[...]

> Well, or the language is explicit about the capture of the new
> value. Is this meant with
> 
> $s.=reverse; # means $s = $s.reverse
> 
> or is this an error that 'abc' is readonly?

$s.reverse returns a reversed copy of $s, and $s.=reverse does the "in
place" reverse, ie it directly modifies $s (but not the string stored in
$s. At least conceptually. But you can't observe the differences, afaict)

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.

(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).

Moritz

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

Re: [perl #58282] [BUG] "elsif defined $a { return $a}" fails

[Moritz Lenz]

Stephen Simmons (via RT) wrote:
> # New Ticket Created by  Stephen Simmons 
> # Please include the string:  [perl #58282]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58282 >
> 
> 
> I wrote a two argument max function, which uses an if/elsif/elsif/else  
> tree; the third case in the statement fails, the rest succeed.
> 
> The code is:
> 
> sub max($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 }
> }
> 
> say "1 <" ~ max(3, 4) ~ ">";
> say "2 <" ~ max(4, 3) ~ ">";
> say "3 <" ~ max(-4, undef) ~ ">";
> say "4 <" ~ max(undef,-2) ~ ">";
> say "5 <" ~ max(undef, undef) ~ ">";
> 
> The output is (except for the comment):
> 
> sully:parrot-0.7.0 stephensimmons$ perl6 ../experiment/max.p6
> 1 <4>
> 2 <4>
> 3 <>   # should have returned -4, similar to test 4, next.
> 4 <-2>
> 5 <>

in trunk, r31178 this gives the desired output (specifically '3 <-4>'),
so I'll close this ticket.

(I suspect it was either a problem with defined() which was improved
lately, or a parsing problem).


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

Re: How to define a new value type?

[TSa]

HaloO,

Darren Duncan wrote:
If you are wanting to actually mutate a Dog in a user-visible way rather 
than deriving another Dog, then I don't think that calling Dog a value 
type is appropriate.


I think that mutating methods of immutable value types just have
to modify the identity. The problem is how that relates to references.
Take e.g. the Str type

   my $s = 'abc'; # $s points to 'abc'
   $s.reverse;

where the reverse method returns a new string that somehow has to
find its way into $s. That is, the method call sequence has to be
different for object types and value types. The start is identical:

   1) fetch pointer from container
   2) bind self to this pointer and call method

For object types this is sufficient because the pointer in the
container remains valid. A value type on the other hand needs

   3) capture new pointer
   4) store new pointer in container

Note that the return value of the method is independent of this
new pointer to the modified value. To unify these two sequences
the system either has to know which type of object the pointer
in the container belongs to or all four steps are executed for
both types where the mutable ones always return the same pointer.
The price to pay for the flexibility of the latter approach is
with expensive store operations of the container.

Well, or the language is explicit about the capture of the new
value. Is this meant with

   $s.=reverse; # means $s = $s.reverse

or is this an error that 'abc' is readonly?


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 #46681] [TODO] [C] Use strerror_r instead of strerror

[Christoph Otto]

chromatic via RT wrote:

On Monday 15 September 2008 23:21:26 Christoph Otto wrote:


--- src/pmc/os.pmc  (revision 31173)
+++ src/pmc/os.pmc  (working copy)
@@ -31,9 +31,6 @@

 #include "parrot/parrot.h"

-/* XXX Check if we need to deallocate strerror strings */
-/* XXX apparently, strerror_r is thread-safe and should be used instead.*/
-
 static PMC *OS_PMC;
 pmclass OS singleton {

@@ -92,9 +89,8 @@
 RETURN(STRING *scwd);
 }
 else {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL,
EXCEPTION_EXTERNAL_ERROR, -errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }


This pattern's almost common enough to tempt me to write 
Parrot_ex_throw_strerror().


-- c




It was also almost enough to make me write Parrot_strerror.  This patch 
contains a file that I neglected to include with the previous one.  Thanks to 
Andy Dougherty for catching that.
Index: src/ops/sys.ops
===
--- src/ops/sys.ops	(revision 31174)
+++ src/ops/sys.ops	(working copy)
@@ -66,13 +66,11 @@
 }
 
 op err(out STR) {
-  const char * const tmp = strerror(errno);
-  $1 = string_make(interp, tmp, strlen(tmp), "ascii", 0);
+  $1 = Parrot_strerror(interp, errno);
 }
 
 op err(out STR, in INT) {
-  const char * const tmp = strerror($2);
-  $1 = string_make(interp, tmp, strlen(tmp), "ascii", 0);
+  $1 = Parrot_strerror(interp, $2);
 }
 
 
Index: src/pmc/os.pmc
===
--- src/pmc/os.pmc	(revision 31174)
+++ src/pmc/os.pmc	(working copy)
@@ -31,9 +31,6 @@
 
 #include "parrot/parrot.h"
 
-/* XXX Check if we need to deallocate strerror strings */
-/* XXX apparently, strerror_r is thread-safe and should be used instead.*/
-
 static PMC *OS_PMC;
 pmclass OS singleton {
 
@@ -92,9 +89,8 @@
 RETURN(STRING *scwd);
 }
 else {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }
 
@@ -118,9 +114,8 @@
 #endif
 string_cstring_free(cpath);
 if (error) {
-char *errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }
 
@@ -141,10 +136,9 @@
 int   error = stat(cpath, &info);
 
 if (error) {
-const char * const errmsg = strerror(errno);
 string_cstring_free(cpath);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 
 if (S_ISDIR(info.st_mode)) {
@@ -155,18 +149,16 @@
 #endif
 string_cstring_free(cpath);
 if (error) {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }
 else {
 error = remove(cpath);
 string_cstring_free(cpath);
 if (error) {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }
 }
@@ -192,9 +184,8 @@
 #endif
 string_cstring_free(cpath);
 if (error) {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 }
 
@@ -231,9 +222,8 @@
 string_cstring_free(cpath);
 
 if (error) {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 else {
 PMC * const array = pmc_new(interp, enum_class_FixedPMCArray);
@@ -296,9 +286,8 @@
 string_cstring_free(cpath);
 
 if (error) {
-const char * const errmsg = strerror(errno);
 Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_EXTERNAL_ERROR,
-errmsg);
+"%Ss", Parrot_strerror(interp, errno));
 }
 else {
 PMC * const array = pmc_new(interp, enum_class_FixedPMCArray);
@@ -343,9 +332,8 @@
 string_cstring_free(cto);
 
 if (error) {
-const char * const errmsg = strerror(errno);
 

Re: How to define a new value type?

[Mark J. Reed]

On Tue, Sep 16, 2008 at 4:26 AM, Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> I don't understand how = differs with that semantic from :=
> I would expect that = would make a copy (clone?) of the object.

Assignment does copy the value between two containers, but in this
case, the value just happens to be a reference to an object.  Binding
makes another name refer to the same container (not the same value).

Imagine that some college roommates have a keyrack near their door
where they keep their car keys, each hook labeled with the occupant
whose key goes there (maybe at the insistence of one particularly OCD
roommate).   Mary's car goes into the shop, but her schedule is such
that she can use John's car when he doesn't need it, so for a while
John and Mary are driving the same car.  If she gets a copy of his key
and puts it on her own hook, that's like assignment.  If she just
peels the label off her hook and moves it next to his hook, that's
like binding.  Either way she's referencing the same object (driving
the same car), but the key copy is a more flexible arrangement.

-- 
Mark J. Reed <[EMAIL PROTECTED]>

[perl #58918] [BUG] Can't use a subdir class twice

[Stephen Simmons]

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


In r31096, use allows a program to use module A and module B, and allows
module B to use module A, when module A defines a method as long as all
three files are in the same directory.  However, when you try and put module
A and module B in the Lib subdirectory and use them as Lib::A and Lib::B,
then rakudo complains with:
A method named 'test' already exists in class 'A'. It may have been supplied
by a role.
current instr.: 'parrot;PCT::HLLCompiler;evalpmc' pc 10631758 ((unknown
file):-1)
perl6(18090) malloc: *** error for object 0x315ad60: double free
*** set a breakpoint in malloc_error_break to debug
Segmentation fault

The attached file illustrates the problem.

System info:
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

Stephen Simmons


use_bug.tar
Description: Unix tar archive

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

[jerry gay]

On Tue, Sep 16, 2008 at 5:14 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Tue Sep 16 00:08:29 2008, [EMAIL PROTECTED] wrote:
>> On Monday 15 September 2008 20:06:11 James Keenan via RT wrote:
>>
>> > See patch attached.  The patch eliminates smartlink-related code from
>> > Parrot, but does not touch anything in languages/.
>>
>> It contains some commented out code that should probably just go away.
>> Otherwise, +1.
>>
>
> Yes, this was a first version of the patch which I rushed out largely to
> see what effect deleting the code would have on the Parrot and Perl 6
> 'make test' suites.  (Answer:  none, accounting for deleted tests.)  My
> plan is to fine tune it by also deleting some comments referring to
> smartlinks in other tests such as t/pmc/object.t.
>
parrot needs a way for us to measure spec coverage in our test suite.
i started the current smartlinks code as an experiment in using moose,
and as a reaction to the mess of smartlink code that's in the pugs
repo. however, i'm not married to the code, so rip it out if you
like--i never completed it, anyway.

a few things about the smartlink code currently in pugs that needs to
be addressed to work well with parrot:
* parrot both follows the parrot design documents, and the perl 6 spec
docs (mainly pge). this is not possible in pugs' system
* it should be well-tested. if pugs' system is used, hopefully the
tests can be used there as well
* it should be easily maintainable. i don't find the pugs' code easy to read.

i'd *love* to see smartlinks working in parrot. one of the big
problems in the parrot test suite is our lack of ability to measure
the test coverage of both code and spec. although smartlinks likely
won't offer us solid quantitative metrics, it will provide important
visual qualitative measures.

oh, one other thing--there was a comment about a perl 6 syntax for
smartlinks somewhere. that's outside the scope of this project, as all
the spec/design docs are written in perl 5 pod. it's something to
think about, but something we'll only address when we have a need
(perhaps when/if the spec docs are rewritten in perl 6 pod?)

~jerry