[PATCH] more tests for spectest_regression
Attached patch adds three more test files (list builtins). The last two tests in joint. are likely to be wrong, and are fudged as such. Further clarification is welcome. More on that in a separate mail. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ Index: t/spectest_regression.data === --- t/spectest_regression.data (revision 28336) +++ t/spectest_regression.data (working copy) @@ -39,12 +39,15 @@ S29-array/push.t S29-array/shift.t S29-array/unshift.t +S29-list/first.t S29-list/grep.t +S29-list/join.t S29-list/map_empty_list.t S29-list/map_flattening.t S29-list/map_function_return_values.t S29-list/map.t S29-list/mutating_listops.t # pure +S29-list/reduce.t S29-list/sort.t S29-num/abs.t S29-num/complex.t
fallback semantics of list methods
In the test suite and on IRC there was quite some confusion about how
list builtins are specced, and how they should behave in corner cases.
One is join():
our Str multi method join ( @values: Str $separator = ' ' )
our Str multi join ( Str $separator = ' ', [EMAIL PROTECTED] )
It is quite clear that the perl 5-style
join 'sep', $value, $value2;
invocation remains valid, and
@list.join($sep)
is the new method form.
The confusion arises what to do with
'str'.join('other_str')
should be.
Fallback semantics in S12 suggest that since no matching multi method is
found, subs are tried - that is, the expression is interpreted as
join('str', 'other_str')
yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
result to be 'str'.
Daniel Ruoso argued in favour of the tested behaviour, suggesting that
perhaps the specs should be updated accordingly, mostly because
('str').join('other_str')
would be confusing otherwise.
Patrick Michaud argued in favour of the specced behaviour, and I agree.
Mostly because nobody sane will write things like
'str'.join('other_str') with a literal string as the invocant in first
place. And if it's not a literal, and you want it to behave as list, the
invocant is either something that returns a list, or a variable with the
'@' sigil. We just need to be careful that everything that should return
really does that, even if it contains a single list.
Currently both pugs and rakudo make return a list (pugs actually
an array, but that's a different problem), but is a Str.
If we'd just be more consistent and always return a list, I don't see a
problem with the spec. If not, it would be rather weird to have .join('c') return 'abc', but .join('c') return 'c'.
Consider
my $x = A.new();
$x.y = ;
say $x.y.join('b')
The output is different for the two possible declarations of class A:
class A { has $y is rw } # -> b
class A { has @y is rw } # -> a
not pretty IMHO.
So I see the following options:
1) be more consistent with what returns a list
2) Add a method with invocant Any for each list builtin
3) drop method fallback, thus disallowing Str.join(Str) outright
4) be lisp, make everything a list *g* (not serious)
I haven't thought a lot about the third option, and what it would mean
to the language as a whole, so I have no idea if it's a viable alternative.
Any thoughts on the topic are welcome. I hope I didn't confuse too much
here ;-)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [PATCH] more tests for spectest_regression
On Sat, Jun 14, 2008 at 4:08 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > > Attached patch adds three more test files (list builtins). > > The last two tests in joint. are likely to be wrong, and are fudged as > such. Further clarification is welcome. > > More on that in a separate mail. > thanks, applied as r28337. ~jerry
Renaming Plumhead
Hi, "Plumhead", from *P*lum*h*eaded *P*arakeet, is the current name of the PHP on Parrot implementation. As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". "Pharrot" is definitly nicer than "Plumhead", but maybe too close to Parrot. Furthermore it changes the 'P' sound that is common to PHP and Parrot to an 'F' sound. The last time "Pharrot"' was used as a project name, it was renamed to "Pint". http://blog.coggeshall.org/archives/290-Back-from-the-Int.-PHP-Conference.html So I'm still open for an alternative. If no better suggestion turns up, I'll rename to 'Pharrot' after the June release. Regards, Bernhard
Re: Renaming Plumhead
Bernhard Schmalhofer wrote: Hi, As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". Problem: "Pharrot" in English is a homonym for "ferret": http://en.wikipedia.org/wiki/Ferret. Are we really sure we want to saddle part of our project with that association? (OTOH, former NYC Mayor Rudy Giuliani fully exposed his sadistic streak when he berated a caller to his radio show for opposing the city ordinance against keeping ferrets as pets. That little incident helped sink his presidential bid -- thankfully, IMO.) kid51
Re: Renaming Plumhead
On Sat, Jun 14, 2008 at 10:23 AM, James E Keenan <[EMAIL PROTECTED]> wrote: > Bernhard Schmalhofer wrote: >> >> Hi, >> > >> >> As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". > > Problem: "Pharrot" in English is a homonym for "ferret": > http://en.wikipedia.org/wiki/Ferret. > > Are we really sure we want to saddle part of our project with that > association? > > (OTOH, former NYC Mayor Rudy Giuliani fully exposed his sadistic streak when > he berated a caller to his radio show for opposing the city ordinance > against keeping ferrets as pets. That little incident helped sink his > presidential bid -- thankfully, IMO.) > > kid51 > I like to think I have a good vocabulary, and I'd never heard of this one, just as a data point. Regards. -- Will "Coke" Coleda
Re: Renaming Plumhead
On Sat, Jun 14, 2008 at 10:32 AM, Will Coleda <[EMAIL PROTECTED]> wrote: > On Sat, Jun 14, 2008 at 10:23 AM, James E Keenan <[EMAIL PROTECTED]> wrote: >> Bernhard Schmalhofer wrote: >>> >>> Hi, >>> >> >>> >>> As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". >> >> Problem: "Pharrot" in English is a homonym for "ferret": >> http://en.wikipedia.org/wiki/Ferret. >> >> Are we really sure we want to saddle part of our project with that >> association? >> >> (OTOH, former NYC Mayor Rudy Giuliani fully exposed his sadistic streak when >> he berated a caller to his radio show for opposing the city ordinance >> against keeping ferrets as pets. That little incident helped sink his >> presidential bid -- thankfully, IMO.) >> >> kid51 >> > > I like to think I have a good vocabulary, and I'd never heard of this > one, just as a data point. > > Regards. > -- > Will "Coke" Coleda > Here's how oblivious I am. I thought you said "synonym", because I couldn't hear "pharrot" as "ferret" but instead as "fair ot" I am now going to go drink more coffee!!! Whoops. -- Will "Coke" Coleda
Re: Renaming Plumhead
Will Coleda wrote: On Sat, Jun 14, 2008 at 10:23 AM, James E Keenan <[EMAIL PROTECTED]> wrote: Bernhard Schmalhofer wrote: Hi, As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". Problem: "Pharrot" in English is a homonym for "ferret": http://en.wikipedia.org/wiki/Ferret. Are we really sure we want to saddle part of our project with that association? (OTOH, former NYC Mayor Rudy Giuliani fully exposed his sadistic streak when he berated a caller to his radio show for opposing the city ordinance against keeping ferrets as pets. That little incident helped sink his presidential bid -- thankfully, IMO.) kid51 I like to think I have a good vocabulary, and I'd never heard of this one, just as a data point. Oxford American Dictionary (aka Apple dictionary applet) never heard of pharrot as well. Cheers Alberto -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: fallback semantics of list methods
On Sat, Jun 14, 2008 at 01:46:10PM +0200, Moritz Lenz wrote:
: In the test suite and on IRC there was quite some confusion about how
: list builtins are specced, and how they should behave in corner cases.
:
: One is join():
: our Str multi method join ( @values: Str $separator = ' ' )
: our Str multi join ( Str $separator = ' ', [EMAIL PROTECTED] )
:
: It is quite clear that the perl 5-style
:join 'sep', $value, $value2;
: invocation remains valid, and
: @list.join($sep)
: is the new method form.
:
: The confusion arises what to do with
:'str'.join('other_str')
: should be.
:
: Fallback semantics in S12 suggest that since no matching multi method is
: found, subs are tried - that is, the expression is interpreted as
:join('str', 'other_str')
: yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
: result to be 'str'.
I want the result to be 'str'.
: Daniel Ruoso argued in favour of the tested behaviour, suggesting that
: perhaps the specs should be updated accordingly, mostly because
:('str').join('other_str')
: would be confusing otherwise.
More to the point,
$unknown.join('other_str')
needs to work well, I think. And that means even if $unknown doesn't
know whether it's singular or plural.
: Patrick Michaud argued in favour of the specced behaviour, and I agree.
: Mostly because nobody sane will write things like
: 'str'.join('other_str') with a literal string as the invocant in first
: place. And if it's not a literal, and you want it to behave as list, the
: invocant is either something that returns a list, or a variable with the
: '@' sigil. We just need to be careful that everything that should return
: really does that, even if it contains a single list.
Patrick and I discussed it on the phone the other day and came to an
understanding, I think.
: Currently both pugs and rakudo make return a list (pugs actually
: an array, but that's a different problem), but is a Str.
: If we'd just be more consistent and always return a list, I don't see a
: problem with the spec. If not, it would be rather weird to have .join('c') return 'abc', but .join('c') return 'c'.
.join('c') should return 'a'.
: Consider
: my $x = A.new();
: $x.y = ;
: say $x.y.join('b')
: The output is different for the two possible declarations of class A:
: class A { has $y is rw } # -> b
: class A { has @y is rw } # -> a
: not pretty IMHO.
Indeed.
: So I see the following options:
: 1) be more consistent with what returns a list
: 2) Add a method with invocant Any for each list builtin
: 3) drop method fallback, thus disallowing Str.join(Str) outright
: 4) be lisp, make everything a list *g* (not serious)
:
: I haven't thought a lot about the third option, and what it would mean
: to the language as a whole, so I have no idea if it's a viable alternative.
I have been advocating for 2, and am considering doing 3 as well.
There's more than one way to do 2--we could, for instance, have some
magical syntax for saying that a class's invocant may be converted
from Any. But what Patrick and I decided on Wednesday was that, for
now, we'd go with the simplest approach, which is not to invent any new
syntax or semantics, but simply have the Prelude install Any methods
as defaults for universal methods such as .join that want to convert
the invocant to a particular type across the language as a whole.
No fallback is then necessary, and the fact that the Prelude is
defining language-wide default semantics is not a problem at all,
because that's precisely what the Prelude is for. And I don't see
any problem with the Any class claiming to own .join since subclasses
can still override if the like.
Larry
[perl #55756] [BUG] nmake realclean fails on windows
On Fri Jun 13 21:35:17 2008, coke wrote: > I can't do an nmake realclean on windows at the moment, because the > O_FILES list is too long. > > A quick fix would probably be to quote the elements and let perl > expand them, rather than letting the shell do it for us. > > A quicker fix is to use a recent version of nmake; version 1.50 apparently has line length problems, version 8.x is fine with our current system. particle++ for pointing this out. Goodness knows how I managed to change the version of nmake I was running. Resolving ticket. -- Will "Coke" Coleda
Re: [perl #41583] Tail calls from within vtable methods broken
I tried to apply Bram's patch from last year, but it had a lot of fuzz
(especially related to the removal of register stacks). Here's what I ended
up with.
It doesn't work, so I'm not applying it as it is... but if there's still a
problem, this might be a better starting point.
-- c
=== include/parrot/interpreter.h
==
--- include/parrot/interpreter.h (revision 28361)
+++ include/parrot/interpreter.h (local)
@@ -279,7 +279,6 @@
#define CHUNKED_CTX_MEM 0 /* no longer works, but will be reinstated
* some day; see src/register.c for details.
*/
-
typedef struct _context_mem {
#if CHUNKED_CTX_MEM
char *data; /* ctx + register store */
@@ -410,6 +409,10 @@
opcode_t *current_args; /* ptr into code w/ set_args op */
opcode_t *current_params; /* ... w/ get_params op */
opcode_t *current_returns;/* ... w/ get_returns op */
+
+parrot_context_t *fromc_result_ctx; /* ptr to context of set_returns,
+ * if we're about to pass return
+ * values to C */
PMC *args_signature; /* non-const args signature PMC */
PMC *params_signature; /* non-const params sig PMC */
PMC *returns_signature; /* non-const returns sig PMC*/
=== include/parrot/register.h
==
--- include/parrot/register.h (revision 28361)
+++ include/parrot/register.h (local)
@@ -108,6 +108,15 @@
void Parrot_set_context_threshold(SHIM_INTERP,
SHIM(struct Parrot_Context *ctxp));
+void copy_context_registers(PARROT_INTERP,
+ARGMOD(struct Parrot_Context *dest),
+ARGMOD(struct Parrot_Context *src))
+__attribute__nonnull__(1)
+__attribute__nonnull__(2)
+__attribute__nonnull__(3)
+FUNC_MODIFIES(*dest)
+FUNC_MODIFIES(*src);
+
void create_initial_context(PARROT_INTERP)
__attribute__nonnull__(1);
=== src/gc/register.c
==
--- src/gc/register.c (revision 28361)
+++ src/gc/register.c (local)
@@ -25,14 +25,14 @@
/* HEADERIZER BEGIN: static */
/* Don't modify between HEADERIZER BEGIN / HEADERIZER END. Your changes will be lost. */
-static void clear_regs(PARROT_INTERP, ARGMOD(parrot_context_t *ctx))
+static void clear_regs(PARROT_INTERP, ARGMOD(Parrot_Context *ctx))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*ctx);
static void init_context(PARROT_INTERP,
-ARGMOD(parrot_context_t *ctx),
-ARGIN_NULLOK(const parrot_context_t *old))
+ARGMOD(Parrot_Context *ctx),
+ARGIN_NULLOK(const Parrot_Context *old))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*ctx);
@@ -210,7 +210,7 @@
parrot_gc_context(PARROT_INTERP)
{
#if CHUNKED_CTX_MEM
-parrot_context_t ctx;
+Parrot_context_t ctx;
if (!interp->ctx_mem.threshold)
return;
@@ -233,7 +233,7 @@
*/
static void
-clear_regs(PARROT_INTERP, ARGMOD(parrot_context_t *ctx))
+clear_regs(PARROT_INTERP, ARGMOD(Parrot_Context *ctx))
{
int i;
@@ -282,8 +282,8 @@
*/
static void
-init_context(PARROT_INTERP, ARGMOD(parrot_context_t *ctx),
-ARGIN_NULLOK(const parrot_context_t *old))
+init_context(PARROT_INTERP, ARGMOD(Parrot_Context *ctx),
+ARGIN_NULLOK(const Parrot_Context *old))
{
ctx->ref_count = 0; /* RT#46191 1 - Exceptions !!! */
ctx->current_results = NULL;
@@ -347,7 +347,7 @@
ctx->n_regs_used[REGNO_NUM] = old->n_regs_used[REGNO_NUM];
ctx->n_regs_used[REGNO_STR] = old->n_regs_used[REGNO_STR];
ctx->n_regs_used[REGNO_PMC] = old->n_regs_used[REGNO_PMC];
-diff= (const long *)ctx - (const long *) old;
+diff= (INTVAL *)ctx - (INTVAL *) old;
interp->ctx.bp.regs_i+= diff;
interp->ctx.bp_ps.regs_s += diff;
@@ -577,6 +577,12 @@
slot= CALCULATE_SLOT_NUM(ctxp->regs_mem_size);
PARROT_ASSERT(slot < interp->ctx_mem.n_free_slots);
+
+#ifndef NDEBUG
+if (ptr == interp->ctx_mem.free_list[slot])
+internal_exception(1,
+"Error: tried to free an already-freed context\n" );
+#endif
*(void **)ptr = interp->ctx_mem.free_list[slot];
interp->ctx_mem.free_list[slot] = ptr;
}
@@ -683,7 +689,47 @@
REG_NUM(interp, i) = 0.0;
}
+/*
+=item C
+
+Copy all registers from one context to another.
+
+=cut
+
+*/
+
+void
+copy_context_registers(PARROT_INTERP, ARGMOD(Parrot_Context *dest),
+ARGMOD(Parrot_Context *src))
+{
+int i;
+int max = src->n_regs_used[REGN
Re: [perl #41620] [PATCH] change opcode syntax for label arguments
On Sunday 25 February 2007 20:12:58 Alek Storm wrote: > This patch changes the , , and INT> syntax in opcodes to , , and LABEL>, respectively. The argument is still an integer, however. > This cuts the number of argument directions down by three, and only > adds one argument type, making the code clearer. This is really an > argument type, after all, not a special kind of direction. I doubt > there will be any confusion about LABEL really being INT, because no > ops do any arithmetic with it; they just use it for > and . Agreed. Thanks, applied as r28359. -- c
Re: Renaming Plumhead
Bernhard Schmalhofer wrote: "Plumhead", from *P*lum*h*eaded *P*arakeet, is the current name of the PHP on Parrot implementation. As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". "Pharrot" is definitly nicer than "Plumhead", but maybe too close to Parrot. Furthermore it changes the 'P' sound that is common to PHP and Parrot to an 'F' sound. The last time "Pharrot"' was used as a project name, it was renamed to "Pint". http://blog.coggeshall.org/archives/290-Back-from-the-Int.-PHP-Conference.html So I'm still open for an alternative. If no better suggestion turns up, I'll rename to 'Pharrot' after the June release. Off the top of my head, I think "Pharrot" isn't a bad choice. Maybe written as "Pherrot?" As an alternative, maybe "Phoebe" or "PHoePe?" ;-) Ron
Re: [perl #41818] [PATCH */4]: [t/op] add tests for string memory layout
On Tuesday 13 March 2007 18:37:21 Sam Vilain wrote: > This is a combined patch submission which I made using a script that > munged output from `git-format-patch HEAD~4`. Thanks, applied as r28362. -- c
Re: [perl #43414] [PATCH] jit_emit.h changes for various platforms
On Thursday 28 June 2007 10:26:31 Paul Cochrane wrote: > as part of my cleaning up the usage of 'INTERP', 'Interp' and > 'interpreter' to consistently use 'interp', as well as changing > internal_exception()s to real_exceptions(), here are some patches > affecting platforms I (unfortunately) don't have access to, so I can't > test them (platforms are: hppa, ia64, ppc and arm). Could someone > please apply these and test them for me? Thanks heaps in advance! Thanks, applied (with fuzz) as r28363. -- c
Re: Renaming Plumhead
From: Ron Blaschke <[EMAIL PROTECTED]> Date: Sat, 14 Jun 2008 21:45:26 +0200 Off the top of my head, I think "Pharrot" isn't a bad choice. Maybe written as "Pherrot?" As an alternative, maybe "Phoebe" or "PHoePe?" ;-) Ron Or "Phoenix"? Does this count as a resurrection from the ashes of Plumhead? ;-} -- Bob
Re: [perl #43529] [PATCH] Add Set assertions
On Wednesday 04 July 2007 06:00:22 Ron Blaschke wrote: > Adds some range check assertions to F. Please > double check if I got them right! > > Assuming the assertions are good there seems to be a problem with its > use, at least for Parrot r19565, Win32, VC++ 8.0. I don't think it's > platform dependent, though. Instead of the asserts, it seems sensible to me to use unsigned int for all set elements. That way the compiler can enforce ranges. I also fixed up all accesses as of r28364. -- c
Re: [PATCH] Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in
On Tuesday 07 August 2007 10:11:20 Andy Dougherty wrote: > This next patch does a little more cleanup on the attributes checking. I > revised config/auto/attributes.pm to use the existing Configure routines > cc_build() and conf->data_add() rather than re-implementing them. I also > removed some now unnecessary #includes"parrot/compiler.h" statements and > cc_inc fiddling in config/init/hints/solaris.pm I've applied everything but the attributes.pm part as r28365, because there was some fuzz and my best approach to getting it to work disabled attribute detection from me. (That's what I get for not applying patches much more frequently; sorry!) I'd take a new patch for the latter, if you're interested. -- c
Re: Renaming Plumhead"
Nobody is claiming that "Pharrot" is a word, just that when pronouned aloud it sounds like "ferret", and people are likely, with the plethora of animal project names floating around, to assume that it is in fact "Ferret" if they hear it before seeing it. On 6/14/08, Bob Rogers <[EMAIL PROTECTED]> wrote: >From: Ron Blaschke <[EMAIL PROTECTED]> >Date: Sat, 14 Jun 2008 21:45:26 +0200 > >Off the top of my head, I think "Pharrot" isn't a bad choice. Maybe >written as "Pherrot?" As an alternative, maybe "Phoebe" or "PHoePe?" ;-) > >Ron > > Or "Phoenix"? Does this count as a resurrection from the ashes of > Plumhead? ;-} > > -- Bob > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
[perl #52710] [PATCH] key.c and missing default in key_integer switch
I fixed this one another way in r27195, working on RT #53356.
[perl #55804] [BUG] Macro typo breaks parrot.
# New Ticket Created by Will Coleda
# Please include the string: [perl #55804]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55804 >
The following pir:
.macro While(code)
.endm
.sub main :main
.While ({
# this comment is required
}
# note missing )
.end
Breaks parrot. If you use the {} syntax, have a non-empty body for it,
but fail to specify the closing paren on the macro invocation, you get
the following stacktrace:
(gdb) bt
#0 0xb7f83402 in __kernel_vsyscall ()
#1 0xb6df12a5 in raise () from /lib/i686/nosegneg/libc.so.6
#2 0xb6df2cf1 in abort () from /lib/i686/nosegneg/libc.so.6
#3 0xb6e2a47c in __libc_message () from /lib/i686/nosegneg/libc.so.6
#4 0xb6e341da in _int_realloc () from /lib/i686/nosegneg/libc.so.6
#5 0xb6e36162 in realloc () from /lib/i686/nosegneg/libc.so.6
#6 0xb7ec008d in read_params (valp=0x0, interp=0x804f040, params=0x82413fc,
macro_name=0x8241470 "While", need_id=0, yyscanner=0x8233958)
at compilers/imcc/imcc.l:944
#7 0xb7ec0854 in expand_macro (interp=0x804f040, name=0x8233f95 "While",
yyscanner=0x8233958) at compilers/imcc/imcc.l:1155
#8 0xb7ebc8b1 in yylex (valp=0xbfc9e308, yyscanner=0x8233958,
interp=0x804f040) at compilers/imcc/imcc.l:538
#9 0xb7eb57cd in yyparse (yyscanner=0x8233958, interp=0x804f040)
at compilers/imcc/imcparser.c:2701
#10 0xb7ec2d8a in compile_to_bytecode (interp=0x804f040,
sourcefile=0xbfc9e9db "foo.pir", output_file=0x0)
at compilers/imcc/main.c:943
#11 0xb7ec315e in imcc_run (interp=0x804f040, sourcefile=0xbfc9e9db "foo.pir",
argc=1, argv=0xbfc9e558) at compilers/imcc/main.c:1046
#12 0x08048978 in main (argc=1, argv=0xbfc9e558) at src/main.c:61
--
Will "Coke" Coleda
[perl #55806] [config] Generate Platform-Independent Includeable Makefile
# New Ticket Created by chromatic # Please include the string: [perl #55806] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55806 > How about we generate a makefile that is full of all the macros we need RM_F, PERL, CP, etc, and include it in all makefiles as they're generated?
Re: [perl #54230] [BUG] [PATCH] Loops in class hierarchies
On Thursday 15 May 2008 14:13:32 NotFound wrote: > Parrot lacks loop avoidance in class hierarchy. This examples segfaults: > > .sub main > $P1 = newclass 'Foo' > addparent $P1, $P1 > .end > > .sub main > $P1 = newclass 'Foo' > $P2 = newclass 'Bar' > addparent $P1, $P2 > addparent $P2, $P1 > .end > > The attached patch modifies add_parent in class, checking that the new > parent is not self, and that none of his parents is. > > It checks the complete list of parents to work the same way even on > override of isa. The intention is to avoid the fault in MRO, not to > forbid experiments with inheritance. > > No tests yet, this patch is for evaluation and discussion. Seems reasonable to me. If you have tests, I'll apply it. -- c
Re: [perl #55804] [BUG] Macro typo breaks parrot.
On Saturday 14 June 2008 15:38:46 Will Coleda wrote:
> The following pir:
>
> .macro While(code)
> .endm
>
> .sub main :main
> .While ({
> # this comment is required
>}
># note missing )
> .end
>
> Breaks parrot. If you use the {} syntax, have a non-empty body for it,
> but fail to specify the closing paren on the macro invocation, you get
> the following stacktrace:
Fixed in r28366. Note that there's no error message given for this case, but
there's no crash. I'm not sure how to make an error message occur.
-- c
[perl #55772] Re: [PATCH] more tests for spectest_regression
# New Ticket Created by Jerry Gay # Please include the string: [perl #55772] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55772 > On Sat, Jun 14, 2008 at 4:08 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > > Attached patch adds three more test files (list builtins). > > The last two tests in joint. are likely to be wrong, and are fudged as > such. Further clarification is welcome. > > More on that in a separate mail. > thanks, applied as r28337. ~jerry
[perl #55768] [PATCH] more tests for spectest_regression
# New Ticket Created by Moritz Lenz # Please include the string: [perl #55768] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55768 > Attached patch adds three more test files (list builtins). The last two tests in joint. are likely to be wrong, and are fudged as such. Further clarification is welcome. More on that in a separate mail. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ Index: t/spectest_regression.data === --- t/spectest_regression.data (revision 28336) +++ t/spectest_regression.data (working copy) @@ -39,12 +39,15 @@ S29-array/push.t S29-array/shift.t S29-array/unshift.t +S29-list/first.t S29-list/grep.t +S29-list/join.t S29-list/map_empty_list.t S29-list/map_flattening.t S29-list/map_function_return_values.t S29-list/map.t S29-list/mutating_listops.t # pure +S29-list/reduce.t S29-list/sort.t S29-num/abs.t S29-num/complex.t
Re: fallback semantics of list methods
Sáb, 2008-06-14 às 09:20 -0700, Larry Wall escreveu:
> On Sat, Jun 14, 2008 at 01:46:10PM +0200, Moritz Lenz wrote:
> : Fallback semantics in S12 suggest that since no matching multi method is
> : found, subs are tried - that is, the expression is interpreted as
> :join('str', 'other_str')
> : yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
> : result to be 'str'.
> I want the result to be 'str'.
Just a sanity check here... Are we really going to change the order of
the parameters of 'join' from p5?
Are we aware that this is going to be a PITA for most p5 developers?
Do we realise that this is only necessary to support
$nonlist.join($separator)
Which, as moritz pointed out on IRC is a very specific corner case,
which only makes sense on something like:
my $a = $cond ?? ( 1 ) !! ( 2, 3, 4 );
$a.join(',');
Which would have the desired effect if used with the proper sigil:
my @a = $cond ?? 1 !! (2,3,4);
@a.join(',');
If we choose to avoid supporting $nonlist.listmethod (which sounds lame
anyway), we can keep the order of parameters in join
join $separator, @list;
join ', ', 1, 2, 3, 4;
Which is considerably saner than:
join 1, 2, 3, 4, ', ';
Moritz convinced me that there's actually no real reason to support
$nonlist.listmethod
And if we stop, and think for more two seconds, we realise that
supporting that could end up having a lot of non-interesting side
effects, because an exported sub with the signature :(Any, Str) is most
likely to have a lot of false hits.
daniel
[perl #55782] [BUG] for 1..1000 -> $a { say $a } segfaults in rakudo (Gargbage Collector)
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #55782]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55782 >
As AnonMonk reported here: http://www.perlmonks.org/?node_id=692090 the line
for 1..1000 -> $a { say $a }
segfaults in rakudo.
The problem can be reproduced by creating a Range with --runcore=gcdebug:
../../parrot --runcore=gcdebug perl6.p
bc -e '1..2'
src/string.c:514: failed assertion '!PObj_on_free_list_TEST(a)'
Backtrace - Obtained 17 stack frames (max trace depth is 32).
(unknown)
Parrot_confess
string_append
Parrot_CodeString_nci_emit
Parrot_NCI_invoke
Parrot_callmethodcc_p_sc
(unknown)
(unknown)
(unknown)
(unknown)
Parrot_runops_fromc_args
Parrot_runcode
(unknown)
imcc_run
(unknown)
__libc_start_main
(unknown)
Aborted
Actually a single constant seems to be unsafe:
../../parrot --runcore=gcdebug perl6.pbc -e '1'
src/string.c:514: failed assertion '!PObj_on_free_list_TEST(a)'
Backtrace - Obtained 17 stack frames (max trace depth is 32).
(unknown)
Parrot_confess
string_append
Parrot_CodeString_nci_emit
Parrot_NCI_invoke
Parrot_callmethodcc_p_sc
(unknown)
(unknown)
(unknown)
(unknown)
Parrot_runops_fromc_args
Parrot_runcode
(unknown)
imcc_run
(unknown)
__libc_start_main
(unknown)
Aborted
Note that compilation alone runs fine (that is ../../parrot
--runcore=gcdebug perl6.pbc -c -e '1..2')
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Renaming Plumhead"
On Jun 14, 2008, at 3:22 PM, Mark J. Reed wrote: Nobody is claiming that "Pharrot" is a word, just that when pronouned aloud it sounds like "ferret", and people are likely, with the plethora of animal project names floating around, to assume that it is in fact "Ferret" if they hear it before seeing it. FWIW, the Ruby/C port of the Lucene search engine is named Ferret. Marvin Humphrey Rectangular Research http://www.rectangular.com/
[svn:perl6-synopsis] r14552 - doc/trunk/design/syn
Author: larry Date: Sat Jun 14 17:06:09 2008 New Revision: 14552 Modified: doc/trunk/design/syn/S05.pod Log: this sentence no verb, diakopter++ Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podSat Jun 14 17:06:09 2008 @@ -346,7 +346,7 @@ The primary intent of these rules is to minimize format disruption when substitution happens across line boundaries and such. There is, -of course, no guarantee that the result will exactly what a human would +of course, no guarantee that the result will be exactly what a human would do. The C<:s> modifier is considered sufficiently important that
[Fwd: Eliminating (?) _handle_darwin_for_macports and _handle_darwin_for_fink]
Hi
Running perl ./Configure.pl in parrot 0.6.2 for the first time on a new
clean install of Mac OS X 10.4.11 with Xcode 2.5 on a PPC G4 12" powerbook
the following oddities appeared four times:
Use of uninitialized value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106
Excerpted output is appended at the end of this message.
Line 106 appears in sub _handle_darwin_for_macports
It is relevant to note that I have neither MacPorts nor Fink installed.
It is also interesting that _handle_darwin_for_fink does not cause this
problem.
So far three methods of cleaning this up have surfaces here at YAPC::NA
Parrot Hackathon:
1) Modify lib/Parrot/Configure/Step/Methods.pm
2) Make _handle_darwin_for_macports be like _handle_darwin_for_fink
3) Eliminate _handle_darwin_for_macports and _handle_darwin_for_fink
We are currently in favor of (3) but we are a bit confused as to
how this was designed to work ... can some one clarify the intent for us?
As for (1), the immediate problem is that if MacPorts is not present then
my $ports_include_dir = $conf->data->get( 'ports_include_dir' );
is undefined (line 105)
and hence line 106
if ( -f qq{$ports_include_dir/$file} ) {
throws the error quoted above.
Although a simplistic 'fix' would be to change line 106 to be
if (defined($ports_include_dir) && -f qq{$ports_include_dir/$file}
) {
it is instructive to compare this routine (_handle_darwin_for_macports)
to the code for _handle_darwin_for_fink. The ..._fink code tests defined-ness
and also tries to reduce duplication of {link,ld,cc}flags.
So, (2) perhaps the ..._fink code should be echoed into the ..._macport code.
However, (3), the more we stare at this the more we are wondering
why do _handle_darwin_for_{macports/fink} even exist ... and why are they
being called four times? The purpose of _handle_darwin_for_macports
seems to be to add MacPorts to Parrot Configure's {link,ld,cc}flags
if needed. Yet the way it is called, MacPorts paths will be added
once for each module that is probed (current four: GMP,readline,pcre,OpenGL).
And why just for these four libraries in config/auto? It seems likely
that requiring each library probe in config/auto to call these routines
is error prone when new probes are added.
Why not just add the MacPorts(Fink) paths *once* at the time of testing
for MacPorts(Fink) existance? And if we did that, might we not be able
to eliminate _handle_darwin_for_macports (and _handle_darwin_for_fink)?
Any thoughts on what (and why) should be done?
Regards,
Todd Olson
= begin excerpt from perl ./Configure.pl ==
Determining if your platform supports GMP...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
no.
Determining if your platform supports readline...Use of uninitialized
value in concatenation (.) or string at
lib/Parrot/Configure/Step/Methods.pm line 106.
dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
dyld: Symbol not found: _rl_get_keymap
Referenced from:
/Users/wparrot01/Documents/Development/mill/001/parrot/0.6.2/
01/./test
Expected in: dynamic lookup
...no.
Determining if your platform supports gdbm..no.
Determining if your platform supports pcre...Use of uninitialized value in
concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm line
106.
...no.
Determining if your platform supports OpenGL...Use of uninitialized value
in concatenation (.) or string at lib/Parrot/Configure/Step/Methods.pm
line 106.
.yes, MacOSX_GLUT 5.
= end excerpt from perl ./Configure.pl ==
[perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing
On Sat Mar 08 09:09:07 2008, [EMAIL PROTECTED] wrote: > rblasch has marked this test as TODO as of r26267. So the file as a > whole is passing (and, at least on Linux, make test is passing), but the > underlying problem is not solved. For the record, situation is unchanged as of time of r28365 today.
[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64
On Mon Apr 14 19:32:46 2008, [EMAIL PROTECTED] wrote: > For the record, we still have two tests SKIPped in this file: > > $ prove -v t/stm/basic_mt.t > t/stm/basic_mt.. > 1..4 > ok 1 - wait (simple) > ok 2 # SKIP Intermittent failures on all platforms > ok 3 # SKIP Intermittent failures on all platforms > ok 4 - wait + invalidate outer transcation > ok > All tests successful. > Files=1, Tests=4, 3 wallclock secs ( 0.01 usr 0.00 sys + 0.10 cusr > 0.01 csys = 0.12 CPU) > Result: PASS For the record, situation remains the same as of r28365 today.
[perl #36407] [BUG] imcc - register allocation
Is there any way we could determine whether this is still a bug? E.g., is there any test we could write for it?
[perl #37993] [BUG] optimized parrot behaves differently than non-optimized (win32-msvc)
Would it be possible to test Parrot on Win32 non-optimized and optimized so as to see whether this is still a bug? Thank you very much.
[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t
Can anyone on FreeBSD give us an update on this issue? Thank you very much. kid51
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
Jonathan, Allison: Can we get an update as to whether this is still a bug? Thank you very much. kid51
[perl #39742] [BUG] installed parrot conflicts with dev parrot.
Can we get an update as to the issues raised in this ticket? Thank you very much. kid51
[perl #46519] [BUG] t/stm/runtime.t test failures
tetragon and I have both noticed that the 1 TODO-ed test in this file has begun to pass as of yesterday. [parrot] 504 $ prove -v t/stm/runtime.t t/stm/runtime1..5 ok 1 - choice (one thread) ok 2 # skip Intermittently failing everywhere ok 3 # skip Intermittently failing everywhere ok 4 - queue adapted for the library # TODO sub bodies aren't properly cloned in threads, RT# 46519 ok 5 - queue (non-blocking; nested) ok 2/5 skipped: various reasons, 1/5 unexpectedly succeeded TODO PASSED test 4 kid51
[perl #41508] [BUG] Configure losing flags...
Coke: We've done some work on config/auto/gmp.pm since this thread was last active. Has it improved the situation for you at all? Thank you very much. kid51
[perl #41883] [BUG] PMETHODs.pm doesn't change back the filename
On Thu Mar 22 15:56:34 2007, tewk wrote: > PCCMETHOD generates some code that doesn't have a source location, which > is OK. > > However, PCCINVOKE generation does neglect to change the c #line > directive back to the original file. This is due to the primitive > emitter in Pmc2c. > > This can be fixed but requires the development of a more feature full > emitter in Pmc2c. tewk: Do you know if this is still an issue? Thank you very much. kid51
[perl #41885] [BUG] All the dynoplibs/dynpmcs fail on freebsd
No objections raised in two months, so I'm marking ticket resolved. kid51
Keep the 'keet Re: Renaming Plumhead
> Bernhard Schmalhofer wrote: >> "Plumhead", from *P*lum*h*eaded *P*arakeet, is the current name of the PHP >> on Parrot implementation. >> As "Plumhead" is a stupid name, Plumhead may sound stupid but there's nothing wrong with Plum-Headed Parakeet spelled correctly with the Hyphen and Three Cap Letters. It's a real bird whose initials spell PHP, what more could you want in a name?. O'Reilly's cover editor will be happy, although they may have to hand-tint the old block to get the evocative colo[u]?ring - they're quite colo[u]?rful, almost pretty in a garish sort of way, which somehow seems appropriate for PHP. http://en.wikipedia.org/wiki/Plum-headed_Parakeet. (One /could/ be obscure and use the latin name http://home.wanadoo.nl/psittaculaworld/Mutations/P-cyanocephala.htm ) If what one wants is a short-form of the name that sounds less goofy than "Plumhead" but still much fewer keystrokes than Plum-Headed Parakeet , perhaps PHPkeet would serve as a logotype for the longer formal name with good pun and allusions, and simultaneously serve as a Google(tm)-able keyword distinct from the aviary variety? -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED]
[perl #36407] [BUG] imcc - register allocation
From: "James Keenan via RT" <[EMAIL PROTECTED]> Date: Sat, 14 Jun 2008 17:13:49 -0700 Is there any way we could determine whether this is still a bug? E.g., is there any test we could write for it? If I try to run the code below (in r28330), I get the following error: [EMAIL PROTECTED]> ./parrot label-test.pir error:imcc:undefined identifier 'foo' in file 'label-test.pir' line 9 [EMAIL PROTECTED]> There is no "foo" on line 9, BTW; I think it really means line 8. In any case, it appears that introducing the label *after* the register declaration makes IMCC forget about the register. This register/label confusion makes it seem likely that the bug in the register allocator still exists -- it may be that IMCC is confusing the RA. If so, then TRT would be to fix IMCC to separate label vs. op/register scope. And the easiest fix would be to decide not to support it at all. -- Bob Rogers http://rgrjr.dyndns.org/ .sub main :main .local pmc foo foo = new 'Integer' foo = 42 if foo goto print foo: print foo print "\n" goto done print: print "there's no foo like an old foo.\n" done: .end
Re: Renaming Plumhead
>From Bernhard Schmalhofer: > As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". > > So I'm still open for an alternative. Parroheep? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #45209] [BUG] parrot considers -0.0 to be true
On Fri Sep 07 10:59:29 2007, colink wrote:
> This test exposes the truthiness/veracity of various numerical constants
> directly, rather than through the examples/tutorial.t test.
>
> The failing test is marked as a TODO.
I'm not sure I understand all the issues Colin raised in this ticket
last year, but I tried out his patch tonight. All tests passed,
including the one that was marked TODO.
So I removed the TODO and committed the attached version to trunk in r28369.
Do we still have a bug? If not, we can close this ticket.
Thank you very much.
kid51
Index: MANIFEST
===
--- MANIFEST(revision 28365)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools\dev\mk_manifest_and_skip.pl Fri Jun 13 09:22:55 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Sun Jun 15 01:05:26 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -3059,6 +3059,7 @@
t/compilers/imcc/syn/scope.t[]
t/compilers/imcc/syn/symbols.t []
t/compilers/imcc/syn/tail.t []
+t/compilers/imcc/syn/veracity.t []
t/compilers/json/from_parrot.t []
t/compilers/json/to_parrot.t[]
t/compilers/pct/NoneGrammar.tg []
Index: t/compilers/imcc/syn/veracity.t
===
--- t/compilers/imcc/syn/veracity.t (revision 0)
+++ t/compilers/imcc/syn/veracity.t (revision 0)
@@ -0,0 +1,129 @@
+#!perl
+# Copyright (C) 2001-2006, The Perl Foundation.
+# $Id$
+
+use strict;
+use warnings;
+use lib qw( . lib ../lib ../../lib );
+
+use Test::More;
+use Parrot::Config;
+use Parrot::Test tests => 5;
+
+pir_output_is( <<'CODE', <<'OUT', "Positive and negative integers" );
+.sub test :main
+$I0 = 1
+unless $I0 goto not_one
+say "1 is true"
+
+not_one:
+$I0 = -1
+unless $I0 goto not_neg_one
+say "-1 is true"
+
+not_neg_one:
+
+end
+.end
+CODE
+1 is true
+-1 is true
+OUT
+
+pir_output_is( <<'CODE', <<'OUT', "Integer zeros" );
+.sub test :main
+$I0 = 0
+if $I0 goto not_zero
+say "0 is false"
+
+not_zero:
+$I0 = -0
+if $I0 goto not_neg_zero
+say "-0 is false"
+
+not_neg_zero:
+
+end
+.end
+CODE
+0 is false
+-0 is false
+OUT
+
+pir_output_is( <<'CODE', <<'OUT', "Positive and negative floats" );
+.sub test :main
+$N0 = 1.0
+unless $N0 goto not_one
+say "1.0 is true"
+
+not_one:
+$N0 = -1.0
+unless $N0 goto not_neg_one
+say "-1.0 is true"
+
+not_neg_one:
+$N0 = 0.5
+unless $N0 goto not_pfive
+say "0.5 is true"
+
+not_pfive:
+$N0 = 1e-33
+unless $N0 goto not_small
+say "1e-33 is true"
+
+not_small:
+end
+.end
+CODE
+1.0 is true
+-1.0 is true
+0.5 is true
+1e-33 is true
+OUT
+
+#TODO: {
+
+#local $TODO = "Failing due to FLOAT_IS_ZERO macro";
+
+pir_output_is( <<'CODE', <<'OUT', "Float zeros" );
+.sub test :main
+$N0 = 0.0
+if $N0 goto not_zero
+say "0.0 is false"
+
+not_zero:
+$N0 = -0.0
+if $N0 goto not_neg_zero
+say "-0.0 is false"
+
+not_neg_zero:
+
+end
+.end
+CODE
+0.0 is false
+-0.0 is false
+OUT
+
+#}
+
+pir_output_is( <<'CODE', <<'OUT', "Float NaN" );
+.sub test :main
+$N0 = 'NaN'
+unless $N0 goto not_nan
+say "NaN is true"
+
+not_nan:
+end
+.end
+CODE
+NaN is true
+OUT
+
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Property changes on: t/compilers/imcc/syn/veracity.t
___
Name: svn:mime-type
+ text/plain
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
[perl #39913] [BUG] TGE - Can't use } in the transform definitions.
pmichaud, allison: Can we get an update on the status of this ticket? Thank you very much. kid51
[perl #44763] [BUG] Assertion fails if PCRE is not available
This is what I'm getting on Linux where Configure.pl says that I do not have PCRE: $ prove -v t/library/pcre.t t/examples/library.t t/library/pcre.. 1..1 ok 1 # SKIP no pcre-config ok t/examples/library.. 1..4 ok 1 - examples/library/getopt_demo.pir ok 2 - examples/library/md5sum.pir ok 3 # SKIP no pcre-config not ok 4 - ncurses_life.pir # TODO ncurses_life.pir not testable yet # Failed (TODO) test 'ncurses_life.pir' # at t/examples/library.t line 77. ok All tests successful. Files=2, Tests=5, 0 wallclock secs ( 0.00 usr 0.00 sys + 0.11 cusr 0.03 csys = 0.14 CPU) Result: PASS Ron, what are you getting now on Windows? kid51
[perl #55808] [CAGE] Test .macro_local syntax
# New Ticket Created by Will Coleda # Please include the string: [perl #55808] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=55808 > Need to test the macro_local syntax. Nothing shows up in t/ -- Will "Coke" Coleda
Re: [perl #55808] [CAGE] Test .macro_local syntax
On Sat, Jun 14, 2008 at 9:03 PM, via RT Will Coleda <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Will Coleda > # Please include the string: [perl #55808] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=55808 > > > > Need to test the macro_local syntax. Nothing shows up in t/ > > -- > Will "Coke" Coleda > Er, first we need to -implement- this syntax. (it's in PDD19, but not in compilers/imcc) -- Will "Coke" Coleda
[perl #52046] [TODO] .hllmacros.pir needs tests
On Mon Mar 24 10:46:02 2008, coke wrote: > This file suffers from bitrot (using the old .local macro syntax > instead of the current .label) > > fix and add a test. > Completed in r28372. -- Will "Coke" Coleda
[perl #24922] [TODO] Need Ops file metadata/hints system
On Mon Mar 17 16:46:37 2008, [EMAIL PROTECTED] wrote: > On Mon Sep 26 21:09:20 2005, jhoblitt wrote: > > > > > So would you like to merge this with 31554 or just close them both? > > > > > RT 31554 was marked Obsolete by Leo in October 2005. Can anyone assess > the current pertinence of the issues raised in this ticket? > > Thank you very much. > kid51 > I'm going to reject this ticket; if I we want to add more information regarding the ops metadata, we should specifically mention the metadata we want to track. Regards. -- Will "Coke" Coleda
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
On Sat Apr 14 15:46:56 2007, allison wrote: > What I get is: > > [oops; continuation 0x188ae28 of type 24 is trying to jump from runloop > 2 to runloop 1] > ok > not ok > > from line 252 of src/pmc/continuation.pmc > > Looks like this is yet-another-example of the inferior runloops problem. > > Throwing an exception from a called sub works just fine: > > .sub main :main > newclass $P0, "Parent" > push_eh handler > "foo"() > print "not " > handler: > print "ok\n" > end > .end > > .sub foo > $P1 = new .Exception > $P1["_message"] = "Blah" > throw $P1 > .end > > Allison If I update the syntax here a bit to what I think is the modern-day parrot analog, I get: $ cat foo.pir .sub main :main newclass $P0, "Parent" push_eh handler $P2 = new "Parent" print "not " handler: print "ok\n" end .end .namespace ["Parent"] .sub __init :method $S0 = typeof self if $S0 != "Parent" goto INIT_OK die "Can not instantiate an interface!" INIT_OK: .end 2;0 [EMAIL PROTECTED]:~/sandbox/parrot$ ./parrot foo.pir [oops; continuation 0x82232f0 of type 21 is trying to jump from runloop 2 to runloop 1] ok not ok ... Which is what allison was saying she got on the older version. If nothing else, the inferior runloop diagnostic here shouldn't be occuring. Let's see how this fairs when we re-merge the pdd25 work back into trunk. -- Will "Coke" Coleda
