Re: [perl #27590] @LOAD with IMCC not always working correctly
Jens Rieks [EMAIL PROTECTED] wrote:
the following patch adds 4 more tests to t/pmc/sub.t
Thanks for the tests. Applied.
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
@LOAD or other pragmas are only evaluated on the first statement of a
compilation unit. Branching inmidst some code isn't supported.
It's not likely that this will get changed. I've updated the test
(including a comment) to now read:
.emit
.pcc_sub _foo:
print error\n
.eom
.emit
.pcc_sub @LOAD _sub1:
print in sub1\n
invoke P1
.eom
leo
Re: newbie question....
Matt Greenwood [EMAIL PROTECTED] wrote: Hi all, I have a newbie question. If the answer exists in a doc, just point the way (I browsed the docs directory). What is the design rationale for so many opcodes in parrot? We have four different register types. They have to be covered by opcode, which leads to a lot of opcode permutations: $ grep -w add docs/ops/math.pod =item Badd(inout INT, in INT) =item Badd(inout NUM, in INT) =item Badd(inout NUM, in NUM) =item Badd(in PMC, in INT) =item Badd(in PMC, in NUM) =item Badd(in PMC, in PMC) =item Badd(out INT, in INT, in INT) =item Badd(out NUM, in NUM, in INT) =item Badd(out NUM, in NUM, in NUM) =item Badd(in PMC, in PMC, in INT) =item Badd(in PMC, in PMC, in NUM) =item Badd(in PMC, in PMC, in PMC) We could of course only provide the very last one but that would prohibit any optimizations. Opcodes with native types running in the JIT code are may tenths faster then their PMC counterparts. ... What are the criteria for adding/deleting them? On demand :) Thanks, Matt leo
Re: [BUG] src/hash.c:256: promote_hash_key: Assertion `key' failed.
Simon Glover [EMAIL PROTECTED] wrote: On Thu, 11 Mar 2004, Jens Rieks wrote: $ tar xzf err2.tgz $ cd err2 $ ../parrot t/pmc/dumper_1.imc parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed. aborted It is caused by 'callmethod dumper' (err2/library/dumper.imc:82) Ah, I stumbled over this yesterday. The problem is that the callmethod STRING op hasn't been implemented yet, Yep. And Parrot was missing an error check for too many arguments. Now it gives: error:imcc:arg count mismatch: op# 723 'callmethod_sc' needs 0 given 1 in file 'library/dumper.imc' line 83 included from 'dumper_1.imc' sub '_dumper' line 20 Simon leo
Re: [BUG] assertion failed in src/packfile.c:2783
Jens Rieks [EMAIL PROTECTED] wrote: $ ../parrot dumper_1.imc parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns pf-const_table-const_count' failed. aborted. Fails differently here: error:imcc:fixup_bsrs: couldn't find addr of sub '__lookup_method' The reason seems to be that (after loading some classes with namespace directive): write fixup '_Data::Dumper::Default::__lookup_method' offs 508 the symbol suddenly appears in this namespace. Did you switch back to the main namespace? namespace [] leo
Re: [BUG] can not call methods with self
On Mar-11, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
attached is a patch to t/pmc/object-meths.t that adds a test that is
currently failing because IMCC rejects code like self.blah()
Yep. It produces reduce/reduce conflicts. Something's wrong with
precedence. I'd be glad if someone can fix it.
The attached patch should remove all of the conflicts, and replace
them with a single shift/reduce conflict that appears to be a bug in
the actual grammar, namely:
x = x . x
can be parsed as
x = x . x
VAR '=' VAR '.' VAR
target '=' var '.' var
assignment
or
x = x . x
VAR '=' VAR '.' VAR
target '=' target ptr target
target '=' the_sub
target '=' sub_call
assignment
Personally, I'd probably also rename 'target' to 'lhs', and 'var' (and
its variants) to 'rhs'. But maybe that's just me. Oh, and 'lhs' is
available because this patch eliminates it.
I didn't try the test mentioned, though.
Index: imcc/imcc.y
===
RCS file: /cvs/public/parrot/imcc/imcc.y,v
retrieving revision 1.125
diff -u -r1.125 imcc.y
--- imcc/imcc.y 11 Mar 2004 16:37:56 - 1.125
+++ imcc/imcc.y 12 Mar 2004 08:33:49 -
@@ -272,7 +272,7 @@
%type sr key keylist _keylist
%type sr vars _vars var_or_i _var_or_i label_op
%type i pasmcode pasmline pasm_inst
-%type sr pasm_args lhs
+%type sr pasm_args
%type symlist targetlist arglist
%token sr VAR
%token t LINECOMMENT
@@ -784,7 +784,7 @@
{ $$ = MK_I(interp, cur_unit, bxor, 3, $1, $3, $5); }
| target '=' var '[' keylist ']'
{ $$ = iINDEXFETCH(interp, cur_unit, $1, $3, $5); }
- | var '[' keylist ']' '=' var
+ | target '[' keylist ']' '=' var
{ $$ = iINDEXSET(interp, cur_unit, $1, $3, $6); }
| target '=' NEW classname COMMA var
{ $$ = iNEW(interp, cur_unit, $1, $4, $6, 1); }
@@ -850,9 +850,9 @@
if ($1-set != 'P')
fataly(1, sourcefile, line, Sub isn't a PMC);
}
- | lhs ptr IDENTIFIER { cur_obj = $1; $$ = mk_sub_address($3); }
- | lhs ptr STRINGC{ cur_obj = $1; $$ = mk_const($3, 'S'); }
- | lhs ptr target { cur_obj = $1; $$ = $3; }
+ | target ptr IDENTIFIER { cur_obj = $1; $$ = mk_sub_address($3); }
+ | target ptr STRINGC{ cur_obj = $1; $$ = mk_const($3, 'S'); }
+ | target ptr target { cur_obj = $1; $$ = $3; }
;
ptr:POINTY { $$=0; }
@@ -916,11 +916,6 @@
| reg
;
-lhs:
- VAR/* duplicated because of reduce conflict */
- | reg
- ;
-
vars:
/* empty */ { $$ = NULL; }
| _vars { $$ = $1; }
@@ -933,7 +928,7 @@
_var_or_i:
var_or_i { regs[nargs++] = $1; }
- | lhs '[' keylist ']'
+ | target '[' keylist ']'
{
regs[nargs++] = $1;
keyvec |= KEY_BIT(nargs);
@@ -952,8 +947,7 @@
;
var:
- VAR
- | reg
+ target
| const
;
Re: Methods and IMCC
Dan Sugalski wrote: Calling a method: object.variable(pararms) Do we need the more explicit pcc_call syntax too: .pcc_begin .arg x .meth_call PObj, (meth | PMeth ) [, PReturnContinuation ] .result r .pcc_end leo
newbie question....
[Matt == [EMAIL PROTECTED] on Thu, 11 Mar 2004 18:06:56 -0500] Matt What is the design rationale for so many opcodes in parrot? Completeness and performance. Many of the opcodes are type-specific variants of other multi-type opcodes. Given that 99+% of parrot code will be automatically generated from language compilers, the performance benefits of additional specialized opcodes outweighs the inability to keep all the opcodes in a human's head at once. Matt What are the criteria for adding/deleting them? Consensus among parrot developers. To be an opcode, a particular function should really need to be implemented in C to work properly. -- [EMAIL PROTECTED] Better to be of a rare breed than a long line. -- TDK
Re: ponie unwell without --gc=libc
On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
If parrot's garbage collector is changed from the default (compacting, IIRC)
to the either libc or malloc, then ponie only fails 6 tests.
As I understand it parrot's default garbage collector will move data blocks
owned by PMCs. However, all of the PMCs ponie generates do not have gc-owned
data attached to them, so there should be no difference.
Sure?
No PerlHash, PerlArray, PerlString?
No pointers to string's data?
...
All PMCs are anchored properly?
Yes. Arthur and I got it down to the appended test case, which is pure C
embedding and extending parrot.
Anyway, to sort out this kind of bugs please provide for ponie two
command line options with these equivalents in imcc/main.c:
-G --no-gc\n
--gc-debug\n
Please UTSL for details. The first turns off DOD GC, the second enables
a switch GC_DEBUG (for which there is an envirnonment setting too:
if (is_env_var_set(PARROT_GC_DEBUG))
Turning off DOD/GC normally shows, if the error is related to that.
Turning on GC_DEBUG does more DODs, e.g. in each string_compare that is
anywhere, where a hash is searched for example.
I hacked this into the ponie source directly for testing. With GC disabled
on the default GC ponie only fails 4 tests (two related to exit codes of ``)
However, the appended test program will segfault (by default) eg:
$ valgrind ./stress_parrot 5000
==9478== Memcheck, a memory error detector for x86-linux.
==9478== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==9478== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==9478== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==9478== Estimated CPU clock rate is 2802 MHz
==9478== For more details, rerun with: -v
==9478==
==9478== warning: Valgrind's pthread_attr_destroy does nothing
==9478== your program may misbehave as a result
==9478== warning: Valgrind's pthread_attr_destroy does nothing
==9478== your program may misbehave as a result
Hello world
==9478== Conditional jump or move depends on uninitialised value(s)
==9478==at 0x805A17F: compact_pool (src/resources.c:301)
==9478==by 0x8059F64: mem_allocate (src/resources.c:149)
==9478==by 0x805A61E: Parrot_reallocate (src/resources.c:500)
==9478==by 0x807227B: expand_hash (src/hash.c:529)
==9478==
==9478== Conditional jump or move depends on uninitialised value(s)
==9478==at 0x805A17F: compact_pool (src/resources.c:301)
==9478==by 0x8059F64: mem_allocate (src/resources.c:149)
==9478==by 0x805A848: Parrot_allocate_string (src/resources.c:634)
==9478==by 0x806B694: string_make (src/string.c:379)
==9478==
==9478== Invalid read of size 4
==9478==at 0x80A2D8C: get_free_object (src/smallobject.c:226)
==9478==by 0x8050A43: get_free_buffer (src/headers.c:87)
==9478==by 0x8050E11: new_string_header (src/headers.c:330)
==9478==by 0x806B645: string_make (src/string.c:367)
==9478== Address 0x44DF0BEC is not stack'd, malloc'd or free'd
==9478==
==9478== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==9478== Address not mapped to object at address 0x44DF0BEC
==9478==at 0x80A2D8C: get_free_object (src/smallobject.c:226)
==9478==by 0x8050A43: get_free_buffer (src/headers.c:87)
==9478==by 0x8050E11: new_string_header (src/headers.c:330)
==9478==by 0x806B645: string_make (src/string.c:367)
==9478==
==9478== ERROR SUMMARY: 6177 errors from 3 contexts (suppressed: 0 from 0)
==9478== malloc/free: in use at exit: 4704588 bytes in 129 blocks.
==9478== malloc/free: 135 allocs, 6 frees, 5087348 bytes allocated.
==9478== For a detailed leak analysis, rerun with: --leak-check=yes
==9478== For counts of detected errors, rerun with: -v
Segmentation fault
It crashes sooner (need less PMCs) with GC debugging turned on (quelle
surprise), and doesn't crash with GC disabled.
Neither Arthur nor myself know where to start in debugging parrot's GC.
Nicholas Clark
/* Needed to turn off GC */
#if 0
#include parrot/parrot.h
#endif
#include parrot/embed.h
#include parrot/extend.h
#include stdio.h
#include stdlib.h
Parrot_PMC make_a_pmc(Parrot_Interp interpreter) {
Parrot_Int type = Parrot_PMC_typenum(interpreter, Integer);
Parrot_PMC p;
p = Parrot_PMC_new(interpreter, type);
Parrot_register_pmc(interpreter, p);
return p;
}
int main (int argc, char**argv) {
int count;
Parrot_Interp interpreter = Parrot_new(0);
Parrot_init(interpreter);
#if 0
/* Turn off GC */
interpreter-DOD_block_level++;
interpreter-GC_block_level++;
#endif
if (argc 1) {
count = atoi(argv[1]);
} else {
count = 100;
}
printf (Hello world\n);
while (count--) {
make_a_pmc(interpreter);
}
printf (Goodbye world\n);
return 0;
}
/* Compile with
gcc -Iinclude -Wall -o stress_parrot stress_parrot.c blib/lib/libparrot.a
-lm
Parrot hijacks SIGINT
Hi, Tracking down test failures in ponie I noticed some tests using SIGINT failing, they don't fail when I change the tests using SIGUSR1, making me think that parrot somehow hijacks SIGINT but not other signals. Is this per design or is it something that should be fixed? Arthur
RE: newbie question....
I completely agree that you would have multiple *of the same* opcode for the different types. I guess the question I was (too delicately) asking, is why you have opcodes that are usually in standard libraries, and even some that aren't. For example; fact, exsec..., why have both concat and add...? Matt -Original Message- From: Leopold Toetsch [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:07 AM To: Matt Greenwood Cc: [EMAIL PROTECTED] Subject: Re: newbie question Matt Greenwood [EMAIL PROTECTED] wrote: Hi all, I have a newbie question. If the answer exists in a doc, just point the way (I browsed the docs directory). What is the design rationale for so many opcodes in parrot? We have four different register types. They have to be covered by opcode, which leads to a lot of opcode permutations: $ grep -w add docs/ops/math.pod =item Badd(inout INT, in INT) =item Badd(inout NUM, in INT) =item Badd(inout NUM, in NUM) =item Badd(in PMC, in INT) =item Badd(in PMC, in NUM) =item Badd(in PMC, in PMC) =item Badd(out INT, in INT, in INT) =item Badd(out NUM, in NUM, in INT) =item Badd(out NUM, in NUM, in NUM) =item Badd(in PMC, in PMC, in INT) =item Badd(in PMC, in PMC, in NUM) =item Badd(in PMC, in PMC, in PMC) We could of course only provide the very last one but that would prohibit any optimizations. Opcodes with native types running in the JIT code are may tenths faster then their PMC counterparts. ... What are the criteria for adding/deleting them? On demand :) Thanks, Matt leo
Re: [perl #27590] @LOAD with IMCC not always working correctly
At 8:27 AM +0100 3/12/04, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
the following patch adds 4 more tests to t/pmc/sub.t
Thanks for the tests. Applied.
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
@LOAD or other pragmas are only evaluated on the first statement of a
compilation unit. Branching inmidst some code isn't supported.
It's not likely that this will get changed.
We need to fix that. Any sub in a compilation unit should be able to
be marked as a LOAD sub, and we ought to be able to have multiple
LOAD subs. (It is, however, perfectly valid for us to automatically
generate the LOAD sub and just have it make calls into all subs
marked LOAD in the compilation unit, though I'd rather not do that)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Methods and IMCC
At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote: Dan Sugalski wrote: Calling a method: object.variable(pararms) Do we need the more explicit pcc_call syntax too: .pcc_begin .arg x .meth_call PObj, (meth | PMeth ) [, PReturnContinuation ] .result r .pcc_end Sure. Or we could make it: .pcc_begin .arg x .object y .meth_call foo .result r .pcc_end to make things simpler. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot hijacks SIGINT
At 12:25 PM + 3/12/04, Arthur Bergman wrote: Hi, Tracking down test failures in ponie I noticed some tests using SIGINT failing, they don't fail when I change the tests using SIGUSR1, making me think that parrot somehow hijacks SIGINT but not other signals. Is this per design or is it something that should be fixed? It'll ultimately be by design--parrot'll end up snagging all the signals. We need to put together some sort of scheme for it, though, since that's untenable in an embedding environment. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Mutating methods
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
: Larry Wall wrote:
: multi sub *scramble (String $s) returns String {...}
: [...]
: Or you can just call it directly as a function:
: scramble(hello)
:
: Can you also call scramble as a class method?
:
: class String is extended {
: method scramble { ..etc... }
: }
:
: String.scramble(hello)
Not unless you write a class method that takes an extra argument.
Otherwise you're passing a class where it expects a string, and a
string where it expects nothing. However, much like in Perl 5 you
can always force which class's method to call with
hello.String::scramble();
But it would work as a class multi, right?
class String is extended {
multi scramble(String $s) {...}
}
hello.scramble();
String::scramble(hello); # Way overspecified for a multi...
=Austin
RE: Mutating methods
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
: So, will mutatingness be a context we'll be able to inquire on
: in the implementation of a called routine?
Probably not, but it's vaguely possible you could somehow get a
reference to what is being assigned to, if available, and check to see
if $dest =:= $src (where =:= tests to see if two refs point to the
same object). But in general I think most want testing is just a
way of making code run slow, because it forces tests to be done at run
time that should be done at compile time or dispatch time. It's better
for the optimizer if you can give it enough type hints and signature
hints to decide things earlier than the body of the sub or method.
: Or, could we provide a specialized distinct implementation
: for mutating that would get called if .=X() is used?
That is much more likely. In general if you don't define both an op
and an op= then Perl can autogenerate or emulate the missing
one for you.
Now in the specific case of . and .= we don't exactly have a normal
binary operator, because the right side is not an expression.
$tis.=««sad pity pity sad sad pity true»;
$s .= ($useMbcs ? wlength : length);
(Side note: although that expression isn't valid, since the wlength
and length methods aren't qualified, it *should* be, since a human could
infer it rather easily. Can we make that DWIM? (One way would be
for the parser to convert that into if-else form if it appeared
ambiguous.))
So we may have to provide a way of marking a normal method as a
mutator. Possibly we end up with
method =sort (Array @ary) returns Array {...} # inplace
method sort (Array @ary) returns Array {...} # cloning
That works nicely with the .= vs . distinction, visually speaking.
Why not just put a property on the calling context, and allow either:
# Run-time handling
method sort(Array @a) { if ($CALLER.mutating) {...} ...}
or
# Properties should be after names
method sort:mutating(Array @a) {...}
or
# But this is consistent with operators
method mutating:sort(Array @a) {...}
On the other hand, you might want to do the same with multi subs:
multi sub =sort (Array @ary) returns Array {...} # inplace
multi sub sort (Array @ary) returns Array {...} # cloning
and then it gets a little more problematic syntactically because
multis are called like subroutines:
=sort(@array);
We would have to allow an initial = at the beginning of a term. So far
I've resisted doing that because I don't want
@obj.meth=foo();
to become ambiguous, in case I decide to make the parentheses optional
on method calls with arguments. If I did decide that, and we have
terms beginning with =, it would not be clear whether the above meant
@obj.meth(=foo());
or
@obj.meth=(foo());
Or @obj.meth = foo();
(As much as I despise those who don't use spaces around the assignment
operator, I'm willing to defend their right to the practice...)
The = prefix notation also doesn't work very well for talking about the
name of a routine:
=sort
That looks an awful lot like a junctive assignment operator...
But it would be obvious from context that it was/n't:
$foo = =sort;
bar(=sort);
$baz =sort;
From a C++-ish perspective, the right thing to do is to differentiate
not by the name but by the declared mutability of the invocant:
multi sub sort (Array @ary is rw) returns Array {...} # inplace
multi sub sort (Array @ary) returns Array {...} # cloning
Or I suppose a case could be made for something that specifically
declares you're returning one of the arguments:
multi sub sort (Array @ary is rw) returns @ary {...} # inplace
After all, it's possible to write a method that mutates its invocant
but *doesn't* return it like a well-behaved mutator should. You don't
always call a mutator in a void context--sometimes you want
to be able to stack mutators:
@array.=sort.=uniq;
So you have to be able to return the mutant as well as mutate it in place.
In the case of mutators, won't the return always be the first argument?
So couldn't we just say:
multi sub sort(Array @ary is rw is mutated) returns Array {...}
multi sub sort(Array @ary) returns Array {...}
(and can't we infer the returns Array when is mutated is provided?)
On the other hand, I'm deeply suspicious of a return signature that
mentions a specific variable. What if the body says to return something
else? Is that just ignored? Do we check it to see if it's the same
item?
No. You might well say:
$string.=length;
And convert from one subtype to another. I think the mutation indicator
is a hint to the optimizer, and a crutch for the implementor, in cases
where it's possible to squeeze more performance out of skipping the
assignment phase. (In particular, where an
Re: Mutating methods
On Fri, 12 Mar 2004 10.51, Damian Conway wrote: There are also cases where something like: $a ||= $b; or: $a += $b; changes the type of value in $a. Should we flag those too? Currently we do warn on the second one if $a can't be cleanly coerced to numeric. Would that be enough for Ccmp= too, perhaps? That triggered a thought about unary operators. What about: $a !=;# i.e., $a = ! $a; Obviously that particular example is a syntax error, but perhaps a more verbose self: version of same would not be. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
RE: Mutating methods
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Larry wrote:
On the other hand, I suspect most people will end up declaring it
int method
self:rotate (int $a is rw) {...}
in any event, and reserve the =rotate for .=rotate, which can never put
the = on the left margin, even if we let ourselves have whitespace
before POD directives. So maybe we just require self: for the
declaration,
and forget about = there.
Yes please!
It interacts badly with global names anyway.
Is it *=sort or =*sort? With *self:sort it's more obvious.
Agreed. I'd *very* much prefer to see reflexive methods like this
declared
Cself:methodname. From a readability stand-point, if for no other
reason.
Boo, hiss.
Two things:
1- I'd rather use inplace than self.
2- I'd rather it be AFTER, than BEFORE, the name, because
method sort
method sort:inplace
reads, and more importantly SORTS, better than
method inplace:sort
method sort
To wit:
method :infix:=(Array, Array) returns Scalar
method :infix:==(Array, Array) returns Boolean
method :infix:!=(Array, Array) returns Boolean
method :infix:===(Array, Array) returns Boolean
method :infix:!==(Array, Array) returns Boolean
method :infix:x(Array) returns Array
method :infix:x:inplace(Array is rw)
### Note: How to handle [undef]? return-undef, or PHP-like push?
method :postfix:[](Array is rw, ?Scalar) returns Scalar
### Inplace-only?
method clear(Array is rw) returns Boolean
method compact(Array) returns Array
method compact:inplace(Array is rw)
### Inplace-only?
method delete(Array is rw, Int) returns WHAT, exactly?
method difference(Array, Array) returns Array #A-B
method differences(Array, Array) returns Array #(A-B) + (B-A)
method exists(Array, Scalar) returns Boolean
method flatten(Array) returns Array
method flatten:inplace(Array is rw) returns Array
method grep(Array, Code) returns Array
method includes(Array, Scalar) returns Boolean
method index(Array, Scalar) returns Int
method intersect(Array, Array)
method is_empty(Array) return Boolean
method join(Array, String)
method length(Array)
method map(Array, Code) returns Array
method pack(Array, String) returns String
method reverse(Array) returns Array
method reverse:inplace(Array is rw)
method rindex(Array) returns Int
### Boy are these likely to be wrong!
method sort(Array, ?Code) returns Array
method sort:inplace(Array is rw, ?Code)
### Inplace-only?
method splice(Array is rw, ?Int, ?Int, ?Array)
method union(Array, Array) returns Array
method unique(Array) returns Array
method unique:inplace(Array is rw)
### Inplace-only?
multi method fill(Array is rw, Scalar, Int, Int)
multi method fill(Array is rw, Scalar, Int)
multi method fill(Array is rw, Scalar, Array)
### Inplace-only?
multi method pop(Array is rw, ?Int) returns Array
multi method pop(Array is rw) returns Scalar
### Inplace-only?
multi method unshift(Array is rw, Scalar) returns Array
multi method unshift(Array is rw, Array) returns Array
### Inplace-only?
multi method push(Array is rw, Array) returns Array
multi method push(Array is rw, Scalar)
### Inplace-only?
multi method shift(Array is rw, Int) returns Array
multi method shift(Array is rw) returns Scalar
multi sub each(Array) returns Iterator # HOW does this work?
(Note also that :...fix sorts better than in-, post-, and pre-. I'd like to
suggest changing
them, since it costs nothing and results in a mild improvement in automation
behavior.)
Another interesting question, if the postfix:.=foo mess is defined
with as self:foo, should infix:+= be defined as self:+ instead?
In other words, should the op= syntax really be a metasyntax like
hyperoperators, where you never actually have to define a C»+«
operator, but the hyperoperator is always autogenerated from ordinary
C+? So basically any infix:op= gets remapped to self:op.
I think that would be cleaner.
Alternatively, is there a valid reason to *need* to define your own
hyperoperator?
That is, can you code C @a +« $x better than C @a.map {return $_ + $x}
? I suspect that it's possible to do so, particularly for such simple cases
as assignment. (Hint: Persistent objects, database, one SQL statement per
assignment.)
So perhaps I should ask for an :infix:=« operator override?
On the other hand, it also means that
someone can say silly things like:
$a cmp= $b
$a ~~= $b
I suppose we could simply disallow meta-= on non-associating operators.
Can anyone come up with a
Re: Mutating methods
Austin Hastings writes: -Original Message- From: Larry Wall [mailto:[EMAIL PROTECTED] On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote: : So, will mutatingness be a context we'll be able to inquire on : in the implementation of a called routine? Probably not, but it's vaguely possible you could somehow get a reference to what is being assigned to, if available, and check to see if $dest =:= $src (where =:= tests to see if two refs point to the same object). But in general I think most want testing is just a way of making code run slow, because it forces tests to be done at run time that should be done at compile time or dispatch time. It's better for the optimizer if you can give it enough type hints and signature hints to decide things earlier than the body of the sub or method. : Or, could we provide a specialized distinct implementation : for mutating that would get called if .=X() is used? That is much more likely. In general if you don't define both an op and an op= then Perl can autogenerate or emulate the missing one for you. Now in the specific case of . and .= we don't exactly have a normal binary operator, because the right side is not an expression. $tis.=sad pity pity sad sad pity true; $s .= ($useMbcs ? wlength : length); (Side note: although that expression isn't valid, since the wlength and length methods aren't qualified, it *should* be, since a human could infer it rather easily. Well, for a slightly more complex expression, a human would have some trouble. This is very likely to be laziness, and we can do without it. There is certainly a way to do this if it is absolutely necessary: my $method = ($useMbcs ?? 'wlength' :: 'length'); $s.=$method; On the other hand, I'm deeply suspicious of a return signature that mentions a specific variable. What if the body says to return something else? Is that just ignored? Do we check it to see if it's the same item? No. You might well say: $string.=length; And convert from one subtype to another. I think the mutation indicator is a hint to the optimizer, and a crutch for the implementor, in cases where it's possible to squeeze more performance out of skipping the assignment phase. (In particular, where an inefficient assignment operator exists.) The last thing we need is another idiom that gets destroyed for efficiency reasons. Once people hear that that is fast, they'll start writing: $string.=length; Instead of what they would usually write, the much cleaner: my $len = $string.length; Even though the latter is only 0.05% slower. Speed has corrupted many programmers. Question: Can all this noise be eliminated by paying more attention to the construction of the assignment operator? That is, do we have an example where $a .= meth is going to perform poorly, and that performance is NOT because of the $a = $a.meth assignment? (And that cannot be fixed by declaring the invocant 'is rw'.) The performance issue is never because of the assignment. Assignment is basically free: it's just copying a pointer. It's usually because of the construction. Constructing a 10,000 element array's going to be expensive, so you'd rather sort in place. Luke
Re: Mutating methods
Larry Wall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Unfortunately we can't just use topicalization to say my Cat $tom = .new() because most people won't expect simple assignment to break their current topic. So another option is to replace = with something that Idoes set the topic for the right side. If we used .= for that, then you'd have to write [...] Another approach would be to have some kind of microtopic that represented the left side of an ordinary assignment. Suppose for the sake of argument that the microtopic is ^. Then you could write @array = ^.sort; and a constructor would be my Kanga $roo = ^.new() But that introduces a new concept that doesn't really generalize well. So forget that. Why are we mixing the concepts of assignment and topicalization -- especially in a way that doesn't generalize. Why can't we invent a topicalization operator, analogous to the old binding operator, that simply sets its LHS as the topic of its RHS: and then have an assigning version of that operator. For example, lets use the section Unicode symbol: § to locally set the current topic within an expression. Now we could say: $x = ( $foo § .a + .b + .c ) to mean $x = $foo.a + $foo.b + $foo.c The assigning version of the operator could be $x §= .foo; my Dog $dog §= .new; Dave.
Re: Mutating methods
On Fri, Mar 12, 2004 at 03:47:22AM -0500, Austin Hastings wrote: -Original Message- From: Larry Wall [mailto:[EMAIL PROTECTED] Now in the specific case of . and .= we don't exactly have a normal binary operator, because the right side is not an expression. $tis.=««sad pity pity sad sad pity true»; $s .= ($useMbcs ? wlength : length); (Side note: although that expression isn't valid, since the wlength and length methods aren't qualified, it *should* be, since a human could infer it rather easily. Can we make that DWIM? (One way would be for the parser to convert that into if-else form if it appeared ambiguous.)) So ... how smart will perl6 be? $o .= (foo,bar,baz); $o .= (expr_returning_method); Since human expectations vary I don't think I want these. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Mutating methods
On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote: : That triggered a thought about unary operators. What about: : : $a !=;# i.e., $a = ! $a; Well, an argument could be made that the corresponding syntax is really: != $a; But you have to read the A op= B == A = A op B transformation differently. Something more like A op= B == mysterylocation = A op B where mysterylocation turns out to be the first actual term, which when A is specified is A, and otherwise B. In other words, dropping the A out gives you both the binary and unary forms: A op= B == mysterylocation = A op B op= B == mysterylocation = op B That could actually be pretty handy for += $a # coerce yourself to numeric ~= $a # coerce yourself to string ?= $a # coerce yourself to boolean On the other hand, if we did that generally, we'd also get operators like: \= $a # turn $a into a reference to itself Yow. : Obviously that particular example is a syntax error, but perhaps a more : verbose self: version of same would not be. Well, it's only a syntax error because we say it's a syntax error. But I do think prefix unarys tend to be more readable than postfix. But, yes, method calls are essentially unary postfix operators. In the OO worldview it's perfectly valid to tell an object to do something to itself. In the functional worldview, of course, keeping any kind of state is viewed with deep suspicion. So really, it's just a matter of whether there's a standard syntax for negate yourself. I don't think there is a large call for it, since most objects don't think of themselves as booleans. But if an object did want to support that behavior, saying $a.self:!(); would certainly be self evident, as it were. It might even come for free with the Boolean role. But then there's the good question of whether to allow the unary op: != $a; Some good questions only have bad answers. This might be one of them. Larry
RE: newbie question....
At 8:55 AM -0500 3/12/04, Matt Greenwood wrote: I completely agree that you would have multiple *of the same* opcode for the different types. I guess the question I was (too delicately) asking, is why you have opcodes that are usually in standard libraries, and even some that aren't. For example; fact, exsec..., I answered this in some detail, but the short answer is There's no reason not to why have both concat and add...? Erm... because they do completely different things? -Original Message- From: Leopold Toetsch [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:07 AM To: Matt Greenwood Cc: [EMAIL PROTECTED] Subject: Re: newbie question Matt Greenwood [EMAIL PROTECTED] wrote: Hi all, I have a newbie question. If the answer exists in a doc, just point the way (I browsed the docs directory). What is the design rationale for so many opcodes in parrot? We have four different register types. They have to be covered by opcode, which leads to a lot of opcode permutations: $ grep -w add docs/ops/math.pod =item Badd(inout INT, in INT) =item Badd(inout NUM, in INT) =item Badd(inout NUM, in NUM) =item Badd(in PMC, in INT) =item Badd(in PMC, in NUM) =item Badd(in PMC, in PMC) =item Badd(out INT, in INT, in INT) =item Badd(out NUM, in NUM, in INT) =item Badd(out NUM, in NUM, in NUM) =item Badd(in PMC, in PMC, in INT) =item Badd(in PMC, in PMC, in NUM) =item Badd(in PMC, in PMC, in PMC) We could of course only provide the very last one but that would prohibit any optimizations. Opcodes with native types running in the JIT code are may tenths faster then their PMC counterparts. ... What are the criteria for adding/deleting them? On demand :) Thanks, Matt leo -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Methods and IMCC
On Mar-12, Dan Sugalski wrote: At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote: Dan Sugalski wrote: Calling a method: object.variable(pararms) Do we need the more explicit pcc_call syntax too: .pcc_begin .arg x .meth_call PObj, (meth | PMeth ) [, PReturnContinuation ] .result r .pcc_end Sure. Or we could make it: .pcc_begin .arg x .object y .meth_call foo .result r .pcc_end to make things simpler. I vote yes -- until we add AST input to imcc, making the args and invocant be line-oriented makes code generation easier for the Perl6 compiler, at least. (Although I might do it the 1st way anyway, just because I spend so much time staring at generated code.) But I had to stare at the .object for a second before I realized you weren't just giving the type of another arg -- would it be better to use .invocant?
Re: Methods and IMCC
At 9:57 AM -0800 3/12/04, Steve Fink wrote: On Mar-12, Dan Sugalski wrote: At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote: Dan Sugalski wrote: Calling a method: object.variable(pararms) Do we need the more explicit pcc_call syntax too: .pcc_begin .arg x .meth_call PObj, (meth | PMeth ) [, PReturnContinuation ] .result r .pcc_end Sure. Or we could make it: .pcc_begin .arg x .object y .meth_call foo .result r .pcc_end to make things simpler. I vote yes -- until we add AST input to imcc, making the args and invocant be line-oriented makes code generation easier for the Perl6 compiler, at least. (Although I might do it the 1st way anyway, just because I spend so much time staring at generated code.) But I had to stare at the .object for a second before I realized you weren't just giving the type of another arg -- would it be better to use .invocant? I don't care either way. Invocant isn't bad as you can do this with non-object things, so object's not quite right. (Though arguably anything you make a method call on really is an object :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
PDD15: per-class attribute offsets
I have some issues with the way attributes are referenced. According to the PDD: classoffset Ix, Py, Sz Returns the offset of the first attribute for class Sz in object Py. getattribute Px, Py, Iz Returns attribute Iz of object Py and puts it in Px. Note that the attribute number is an absolute offset. So, compilers are expected to know the relative offsets of attributes within each class? That's reasonable enough, assuming that attributes are only directly accessed by code whose objects' classes have been declared. addattribute Px, Sy Add attribute Sy to class Px. This will add the attribute slot to all objects of class Px and children of class Px, with a default value of Null. Should we just try to ensure that any class which wants to add attributes to itself always uses the named version of getattribute? Do we allow code which modifies other classes' attribute lists? Do we need to mark classes as numeric/named attribute access, and restrict addattribute's use to classes which use named attributes? As well as involving much finding of instances, and moving of their attribute values, this isn't thread safe (please excuse my lack of PASM syntax knowledge): classoffset Ioff, Pobj, Sclass # Some other thread calls addattribute on Pobj's class getattribute Pattr,Pobj,Ioff # Now we have the value of the wrong attribute in Pattr -- Peter Haworth [EMAIL PROTECTED] There is no reason to use multithreading except if you are a marketing guy at Sun or Microsoft and your analysis says that it is cheaper to ram multithreading down people's throats than to fix the insanely huge process creation latency of your broken poor excuse of an operating system. -- Felix Leitner
Re: newbie question....
Matt Greenwood wrote: why have both concat and add...? How, exactly, is taking two strings, making a third string that's big enough to contain both, and copying the contents of those two strings into the third one like taking two numbers, doing a binary OR with carry, and storing the result in a third number? Some languages overload addition to do both. Other languages don't; in fact, a Perl add and a Perl concat (to take one example) behave very differently from one another. Generally speaking, it's better for compilers to do a bit of extra work to figure out the argument types involved than it is for them to throw away information they already have. (Besides, it's not that big a deal with PMCs--a PythonString can put the same code in its concat_*() and add_*() vtable entries.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: PDD15: per-class attribute offsets
At 6:14 PM + 3/12/04, Peter Haworth wrote: I have some issues with the way attributes are referenced. According to the PDD: classoffset Ix, Py, Sz Returns the offset of the first attribute for class Sz in object Py. getattribute Px, Py, Iz Returns attribute Iz of object Py and puts it in Px. Note that the attribute number is an absolute offset. So, compilers are expected to know the relative offsets of attributes within each class? That's reasonable enough, assuming that attributes are only directly accessed by code whose objects' classes have been declared. Yes. The assumption is that the compiler is keeping track of the class its building. That seems reasonable, though you may run into issues with classes whose definitions are scattered across multiple independently loaded bytecode files. I'm OK with putting a Don't *do* that! in the docs, though. :) addattribute Px, Sy Add attribute Sy to class Px. This will add the attribute slot to all objects of class Px and children of class Px, with a default value of Null. Should we just try to ensure that any class which wants to add attributes to itself always uses the named version of getattribute? Nope, not needed. If a class adds an attribute, it always goes on the end of the attribute set for that class. Presumably (a presumption I'm comfortable with) the code doing the adding knows that there are already N attributes, and that its adding attribute N+1 to the list. (I'm assuming the common case will be eval'ing source, in which case the compiler can see the current layout and emit appropriate bytecode for the new number) Do we allow code which modifies other classes' attribute lists? Do we need to mark classes as numeric/named attribute access, and restrict addattribute's use to classes which use named attributes? No (sorta) and no, respectively. Removing a used attribute strikes me as a Bad Thing, and I can't think of a reason to do it that shouldn't result in horrible flaming death and bizarre behaviour. And adding attributes, since they always go on the end of a class' list of attributes, is harmless. As well as involving much finding of instances, and moving of their attribute values, this isn't thread safe (please excuse my lack of PASM syntax knowledge): Yeah, adding an attribute requires a stop-the-world action, as every object that has the modified class needs to be modified. That's a non-trivial activity. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: newbie question....
How, exactly, is taking two strings, making a third string that's big enough to contain both, and copying the contents of those two strings into the third one like taking two numbers, doing a binary OR with carry, and storing the result in a third number? Firstly, you have made an assumption that the addition here is equivalent to OR and carry, which may be correct for certain representations of integral datatypes, but certainly isn't for any kind of floating point arithmetic that I know of. Secondly, you missed the point that I was making. The current add opcodes defined in parrot are the following: add (in PMC, in PMC, in PMC) add(in PMC, in INT) add(in PMC, in NUM) add(in PMC, in PMC) add(in PMC, in PMC, in INT) add(in PMC, in PMC, in NUM) add(inout INT, in INT) add(inout NUM, in INT) add(inout NUM, in NUM) add(out INT, in INT, in INT) add(out NUM, in NUM, in INT) add(out NUM, in NUM, in NUM) I was simply asking why there wasn't an add(out STR, in STR, in STR) which seems reasonable. This is not a question of operator overloading, but rather semantics - that's all. Some languages overload addition to do both. Other languages don't; in fact, a Perl add and a Perl concat (to take one example) behave very differently from one another. Ahh yes, but this includes implicit type conversion, which is not what you want to do in Parrot (if I am to understand Dan correctly) DanS Right now it's flat-out disallowed in parrot, and I'm also DanS comfortable with that. (Plan on keeping it that way, honestly) Generally speaking, it's better for compilers to do a bit of extra work to figure out the argument types involved than it is for them to throw away information they already have. (Besides, it's not that big a deal with PMCs--a PythonString can put the same code in its concat_*() and add_*() vtable entries.) Agreed, though in this case it's the opposite. The compiler doesn't need to do any extra work because it knows exactly what argument types it has. Thanks, Matt
Re: [perl #27590] @LOAD with IMCC not always working correctly
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:27 AM +0100 3/12/04, Leopold Toetsch wrote: @LOAD or other pragmas are only evaluated on the first statement of a compilation unit. Branching inmidst some code isn't supported. It's not likely that this will get changed. We need to fix that. Any sub in a compilation unit should be able to be marked as a LOAD sub, and we ought to be able to have multiple LOAD subs. Any PIR sub is its own compilation unit, that's not the problem. Above applies only to: .emit .pcc_sub @LOAD _label1: ... .pcc_sub @LOAD _label2: .eom I'll not gonna change that. It's simple to split above: .emit .pcc_sub @LOAD _label1: .eom .emit .pcc_sub @LOAD _label2: .eom leo
Re: Methods and IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: ... (Though arguably anything you make a method call on really is an object :) or a class. leo
Re: [BUG] can not call methods with self
Steve Fink [EMAIL PROTECTED] wrote: The attached patch should remove all of the conflicts, and replace them with a single shift/reduce conflict that appears to be a bug in the actual grammar, namely: x = x . x Ah yes. Or course, Thanks a lot, applied. leo
Re: Methods and IMCC
At 8:34 PM +0100 3/12/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: ... (Though arguably anything you make a method call on really is an object :) or a class. Well... only because classes are objects. Or objects are classes. Possibly both, this OO stuff confuses me sometimes. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: newbie question....
Matt Greenwood wrote: Firstly, you have made an assumption that the addition here is equivalent to OR and carry, which may be correct for certain representations of integral datatypes, but certainly isn't for any kind of floating point arithmetic that I know of. True enough, but I think I got my point across--concatenation is a fundamentally different operation from addition. Secondly, you missed the point that I was making. The current add opcodes defined in parrot are the following: (various combinations of PMC, INT, and NUM) I was simply asking why there wasn't an add(out STR, in STR, in STR) which seems reasonable. This is not a question of operator overloading, but rather semantics - that's all. I suppose that depends on what you want it to do. If you want it to convert $2 and $3 to integers, add them, convert the result to a string, and put it in $1, then the answer is that's not a common enough operation to warrant adding the extra opcodes--especially since the I/S/N registers aren't supposed to be used for anything but optimizations. If you want it to concatenate $2 and $3 and insert the result into $1, and remove the concat opcode altogether...well, the answer stems from the existence of add(in PMC, in PMC, in PMC). What should that do--integer addition, or string concatenation? Remember, some of our languages don't overload add for strings. We need a separate concat(in PMC, in PMC, in PMC), so we might as well have concat(out STR, in STR, in STR) too. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Using Ruby Objects with Parrot
Hi, I've been reading PDD15. It seems that if the object foo is an instance of the class Foo then foo is a ParrotObject pmc and Foo is a ParrotClass pmc. From the description in PDD15 I'm not sure how to hand languages where a class is also an object. Where Foo is an instance of Foo' which is an instance of Class. The three solutions I can see are 1: Let one ParrotObject be an instance of another ParrotObject, so that Ruby would just use ParrotObjects for it's object system 2: Let one ParrotClass be an instance of another ParrotClass 3: Create a ParrotMetaClass pmc, so Class and Foo' would be ParrotMetaClasses, Foo would be a ParrotClass and foo would be a ParrotObject I think this will also be an issue with Python since that allows classes to have metaclasses. -- Mark Sparshatt
[BUG] can not use op names as sub/method name
Hi, .namespace [Source] .sub open method .pcc_begin_return .pcc_end_return .end fails with error:imcc:parse error, unexpected PARROT_OP, expecting IDENTIFIER jens
[BUG] method calling problem
Hi, another day, another bug... :-) $ tar xzf err4.tgz $ cd err4 $ ../parrot main.imc main.imc: calling method readFile... get_string() not implemented in class 'SArray' I can not see whats wrong with it. It works only if the called method does not use .param... jens err4.tgz Description: application/tgz
More object stuff
Okay, so I'm fiddling around in the guts of the object system getting the groundwork laid for some speed increases (I hope--we're just barely faster than perl 5 when doing the equivalent of perl's tie with the base object type) and one thing occurred--should we have the base object system participate in multimethod dispatch? That is, if someone does an: add P1, P2, P3 and P2 is a parrot object, should that add vtable method automatically redispatch to MMD if the vtable method can't be found in P2's class hierarchy? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Configure changes
Okay, I was going to wait till I finished, but with Real Life interfering as it has the last couple days, I'd like to get something out on the list for Piers to link to. ;^) I've made some fairly significant changes to Configure in the last week or so. Starting from the top: 1. If you auto-generate a chunk of Makefile and want to shove it into Configure::Data, use a TEMP_ prefix on the key. That way, it'll be stripped out before finding its way to Parrot::Config and library/config.imc. 2. Configure steps should not output anything under normal circumstances--not even if it's in parentheses or square brackets. The '--verbose' switch is suggested for a small amount of output. (The old use of '--verbose'--to print out every single write to Configure::Data--is now available by using '--verbose=2'.) 3. Miniparrot's settings are now all in one place, rather than being scattered across a dozen steps. That doesn't mean that miniparrot's actually building, as mentioned in a thread earlier this week. 4. I've already combined a few steps in config/gen; config/auto will see more extensive combinations. When I'm done, the Configure output will look something like this: Checking MANIFEST..done, Setting up Configure's data structures.done. Tweaking settings for miniparrot...done. Loading platform and local hints files.done. Enabling optimization..done. Determining nongenerated header files..done. Determining what C compiler and linker to use..done. Determining what types Parrot should use...done. Determining what opcode files should be compiled indone. Setting up experimental systemsdone. Determining what pmc files should be compiled in...done. Probing for C headers..done. Probing your types.done. Determining architecture, OS and JIT capabilitydone. Determining what allocator to use..done. Probing your C compilerdone. Probing your standard C librarydone. Configuring ICU if requested...done. Generating C headers...done. Generating runtime/parrot/include..done. Generating core pmc list...done. Generating build files.done. Moving platform files into place...done. Recording configuration data for later retrieval...done. A lot of specialized steps (such as Determining if your C library supports memalign and Verifying that the compiler supports function pointer casts) will be combined into a few more general steps in this scheme. It'd be nice to rename some of the steps once I'm finished with them, to reflect their new functions. IIRC that's a hassle, though, so I'm not by any means going to insist on it. Comments welcome on any part of this whole scheme. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Using Ruby Objects with Parrot
At 10:22 PM + 3/12/04, Mark Sparshatt wrote: Hi, I've been reading PDD15. It seems that if the object foo is an instance of the class Foo then foo is a ParrotObject pmc and Foo is a ParrotClass pmc. From the description in PDD15 I'm not sure how to hand languages where a class is also an object. Where Foo is an instance of Foo' which is an instance of Class. Okay, I'm going to be dense here for a bit, as I just don't do objects. (Well, except grudgingly, and with an inordinate amount of grumbling) So the big question is... What Does This Mean? I'm reasonably sure (though not 100% sure) that classes can only inherit from classes, not objects, so there's none of this template object stuff to deal with. The ParrotObject PMC inherits from the ParrotClass PMC, so there's a lot of overlap, so... what can one do with a class that makes it a metaclass? (Yeah, I do realize I'm more or less asking a Recap the last 30 years of OO theory for Dummies question, but I'm not sure I'm familiar enough with things to ask a better one) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] can not use op names as sub/method name
Jens Rieks [EMAIL PROTECTED] wrote: Hi, .namespace [Source] .sub open method .pcc_begin_return .pcc_end_return .end fails with error:imcc:parse error, unexpected PARROT_OP, expecting IDENTIFIER Parrot opcode names are basically reserved words. There are some exceptions, where the lexer gets hints that now an identifier is expected, but this hints aren't by far everywhere. I know that this is suboptimal but fixing it for every piece in the parser is difficult. I'll have a look at above case, though. jens leo
Re: Configure changes
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Comments welcome on any part of this whole scheme. I really like the cleanup. But the whole scheme needs more steps: That's mainly probing for much more items, e.g. threads, signals, socket stuff, which isn't quite simple. You first have to determine necessary headers before you can try to probe for functions (s. inet_aton vs inet_pton). I think that the Fhints/ should contain more information. When you know its a POSIXish system or Win32 you can make some assumptions and continue from there. leo
Re: Using Ruby Objects with Parrot
Mark Sparshatt wrote: From the description in PDD15 I'm not sure how to hand languages where a class is also an object. Where Foo is an instance of Foo' which is an instance of Class. Could this be handled during compilation? The compiler could produce the classes Foo and Foo' and use something like Ruby-Class from a library. Then Foo could contain a hidden reference to Foo', using a convention that the compiler can handle. I would expect that the dependency on Ruby-libraries still exist, when running compiled Ruby anywhere where Perl6 has been installed. Best regards, Karl
Re: Mutating methods
Larry Wall wrote:
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say given.
my Dog $dog given= .new;
Where 'given' is 'wa'.
Unfortunately, it's backwards compared to the statement modifiers Perl
already has. That suggests
=.new given my Dog $dog;
but that requires the unary equals you apparently don't like *and* puts
the less important bit on the LHS.
Bah. Just use 'wa' and make the world learn Japanese. :^P
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Mutating methods
Oh, it's got lots of Japanese in it, I'd better read it... :)
[EMAIL PROTECTED] (Larry Wall) writes:
Some will argue that since English doesn't have a grammatical
postfix topicalizer like Japanese, we should stick with something
like more English-like:
$x = (.a + .b + .c given $foo)
I think I'm missing something here. We have given as a perfectly good
topicaliser. Now, I remember harping on a while ago about generalizing the
idea of some control structures returning values, such as $x = if $a { $b }
else { $c };
Now if we do generalise that, we get
$x = given $foo { .a + .b + .c };
which gives us the topic-in-front form, the given which is the standard way
of declaring the topic, and it's all nice.
my Dog $dog wa= .new;
Urgh. This reads like you're topicalising a $dog, assigning to it and
acting on it all at the same time. Too many particles!
my Dog $inu wa ga o new desu; # ? :)
So you could usefully say something like
$modthingie wa %= .modulus;
Hrm.
given($modthingie) %= .modulus;
might work, but it relies on a few pieces of underlying magic, none of which I
believe to be over-the-top in themselves but taken together may leave a bad
taste:
control structures return a value, as above
given takes an optional block, purely setting the topic if no block
the topic persists throughout a statement
if operator it is.
I don't think it's an operator so much as a function. It sets the
topic and, depending on how things turn out, returns either void or
the topic again.
--
teco /dev/audio
- Ignatios Souvatzis
Latin-1-characters
And I do think people would rebel at using Latin-1 for that one. I get enough grief for :-) I can imagine that these cause some trouble with people using a charset other than ISO-8859-1 (Latin-1) that works well with 8 bit, like Greek, Arabic, Cyrillic and Hebrew. For these guys Unicode is not so attractive, because it kind of doubles the size of their files, so I would assume that they tend to do a lot of stuff with their koi-8 or with some ISO-8859-x not containing the desired character. For it might not be such a problem, because would work instead. Maybe this issue could (will?) be addressed by declaring the charset in the source and using something like (or better than) \u00AB for stuff that this charset does not have, using a charset-conversion to unicode while parsing the source. This looks somewhat cleaner to me than just pretending a source file written in ISO-8859-7 (Greek) were ISO-8859-1 (Latin-1), relying on the assumption that the two characters we use above 0x80 happen to be in the same positions 0xab and 0xbb. Sorry if that is an old story... Best regards, Karl
Re: ponie unwell without --gc=libc
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote:
All PMCs are anchored properly?
Yes. Arthur and I got it down to the appended test case, which is pure C
embedding and extending parrot.
I already had mailed earlier with Arthur about that very problem. Parrot
needs a stack_limit (interprer-lo_var_ptr) for stack tracing. This
includes tracing processor registers which are placed on the stach in
trace_system_areas(). When this stack limit isn't set, stack walking can
not be done and all PMCs in hardware CPU registers and on the stack are
missed, which normally leads to ugly DOD bugs - they are really hard to
trace down.
So you have two possibilities to set the stack limit:
interpreter-lo_var_ptr = interpreter; // a local in the outermost
// stack frame
or better, you run all your code through the wrapper:
- Parrot_run_native()
which enters a run loop after doing normal initialization (which
includes setting up a Parrot_exception which is used for exception
handling. The ops that get run are enternative yourcode ; end;
Below is a working revision of your code.
(I know, that extend.c is missing some bits but that shouldn't be the
problem, we have just to add it)
leo
/* Needed to turn off GC */
#if 1
#include parrot/parrot.h
#endif
#include parrot/embed.h
#include parrot/extend.h
#include stdio.h
#include stdlib.h
Parrot_PMC make_a_pmc(Parrot_Interp interpreter) {
Parrot_Int type = Parrot_PMC_typenum(interpreter, Integer);
Parrot_PMC p;
p = Parrot_PMC_new(interpreter, type);
Parrot_register_pmc(interpreter, p);
return p;
}
static opcode_t*
run( Parrot_Interp interpreter, opcode_t *cur_op, opcode_t *start)
{
int count = REG_INT(5); // fake argv passing - its normally P5
printf (Hello world %d\n, count);
while (count--) {
if (! (count 0xfff)) {
printf(.);
fflush(stdout);
}
make_a_pmc(interpreter);
}
printf (Goodbye world\n);
return NULL;
}
int
main (int argc, char**argv) {
int count;
Parrot_Interp interpreter = Parrot_new(0);
Parrot_init(interpreter);
#if 0
/* Turn off GC */
interpreter-DOD_block_level++;
interpreter-GC_block_level++;
#endif
if (argc 1) {
count = atoi(argv[1]);
} else {
count = 100;
}
REG_INT(5) = count ; // fake argv passing
Parrot_run_native(interpreter, run);
Parrot_exit(0);
return 0;
}
/* Compile with
gcc -Iinclude -Wall -o stress_parrot stress_parrot.c blib/lib/libparrot.a
-lm -ldl -lpthread # Don't need these on *BSD :-)
*/
Re: ponie unwell without --gc=libc
On 12 Mar 2004, at 19:26, Leopold Toetsch wrote: Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote: All PMCs are anchored properly? Yes. Arthur and I got it down to the appended test case, which is pure C embedding and extending parrot. I already had mailed earlier with Arthur about that very problem. Parrot needs a stack_limit (interprer-lo_var_ptr) for stack tracing. This includes tracing processor registers which are placed on the stach in trace_system_areas(). When this stack limit isn't set, stack walking can not be done and all PMCs in hardware CPU registers and on the stack are missed, which normally leads to ugly DOD bugs - they are really hard to trace down. I think this idea is flawed when it comes to embedding and extending. Parrot should never walk the stack outside of itself (the embedding applications stack should be off limit). Also note that in this example, there never are any dead objects to find. So you have two possibilities to set the stack limit: interpreter-lo_var_ptr = interpreter; // a local in the outermost // stack frame I can't do this from embedding space since the internals of interpreter are not known. or better, you run all your code through the wrapper: - Parrot_run_native() which enters a run loop after doing normal initialization (which includes setting up a Parrot_exception which is used for exception handling. The ops that get run are enternative yourcode ; end; I am sorry, but all I can say is yuck, you can't expect embedders to have to wrap their main in Parrot. Below is a working revision of your code. (I know, that extend.c is missing some bits but that shouldn't be the problem, we have just to add it) leo /* Needed to turn off GC */ #if 1 #include parrot/parrot.h #endif This is the luxury I cannot do :( In fact, as an embedder, I cannot be sure I always have a local variable on a stack frame available to me, so I will end up having to set lo_var_ptr every time I call into the parrot API, hence I suggest this setting should be in extend.c and embed.c Arthur
Re: ponie unwell without --gc=libc
Arthur Bergman [EMAIL PROTECTED] wrote: On 12 Mar 2004, at 19:26, Leopold Toetsch wrote: ... When this stack limit isn't set, stack walking can not be done and all PMCs in hardware CPU registers and on the stack are missed, which normally leads to ugly DOD bugs - they are really hard to trace down. I think this idea is flawed when it comes to embedding and extending. Parrot should never walk the stack outside of itself (the embedding applications stack should be off limit). If you are using Parrot_run_native(), Parrot sets the stack limit to the level at it's run loop. (This was the final solution at the Parrot BOF on Sat at YAPC EU - if you remember :) This is the stack of itself. But you are missing the point: If the limit is *not* set, Parrot doesn't do any stack walking, which implies *no* walking of hardware CPU registers. Also note that in this example, there never are any dead objects to find. So your are sure, that your compiler never puts a local into a CPU register, that in all intermediate function calls the returned PMC is already anchored in the root set? That's just not true. While there are no dead objects, there are unanchored objects, which get happily destroyed, because Parrot doesn't find them to be alive. Your test program and mine are showing that your assumptions are wrong. I can't do this from embedding space since the internals of interpreter are not known. or better, you run all your code through the wrapper: - Parrot_run_native() which enters a run loop after doing normal initialization (which includes setting up a Parrot_exception which is used for exception handling. The ops that get run are enternative yourcode ; end; I am sorry, but all I can say is yuck, you can't expect embedders to have to wrap their main in Parrot. Take it or leave it. Its one function call. Its easy. It does the Right Thing for setting up everything. What's the problem? #if 1 #include parrot/parrot.h #endif This is the luxury I cannot do :( You had snipped away my comment, that the extending interface needs some extensions, *if* we finally agree, what are your needs. In fact, as an embedder, I cannot be sure I always have a local variable on a stack frame available to me, so I will end up having to set lo_var_ptr every time I call into the parrot API, hence I suggest this setting should be in extend.c and embed.c Providing a function call that sets the stack limit ins't the problem. Doing it right is the problem. First you should paint a picture of Ponie's stack layout: Where is the interpreter constructed, where do you call into Parrot ... The range from the stack limit down the call chain to the actual call into Parrot API has to cover all possible auto (stack) Buffer and PMC variables. Arthur leo
CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
This is Ponie, development release 2 And, isn't sanity really just a one-trick ponie anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit. -- the tick Welcome to this second development release of ponie, the mix of perl5 and parrot. Ponie embeds a parrot interpreter inside perl5 and hands off tasks to it, the goal of the project is to hand of all data and bytecode handling to parrot. With this release all internal macros that poke at perl data types are converted to be real C functions and to check if they are dealing with traditional perl data types or PMC (Parrot data types) data. Perl lvalues, arrays and hashes are also hidden inside PMCs but still access their core data using traditional macros. The goal and purpose of this release is to make sure this approach keeps on working with the XS modules available on CPAN and to let people test with their own source code. No changes where made to any of the core XS modules. This is based on perl 5.9.1 as it existed in September, when 5.9.1 is really released ponie will be updated to that version, this might lead to there being perl bugs in ponie that are fixed in later versions on ponie. If you embed perl, nothing should have changed but parrot takes control over a substantial part of the interface to the operating system, this might cause problems for you. (One example is that parrot seems to hijack SIGINT currently, and weird issues with STDERR). --- Enjoy Arthur
