Re: Mutating methods
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)
A
Re: Mutating methods
Larry Wall wrote: Yet another approach is to *replace* dot with something that mutates: @array!sort @array?sort Either of those would work syntactically in that case, since neither ! nor ? is expected as a binary operator. What about ? is as a ternary operator: @foo?bar:baz; Or am I missing.something? A
Re: Mutating methods
AW == Andy Wardley [EMAIL PROTECTED] writes: AW What about ? is as a ternary operator: AW @foo?bar:baz; IIRC, that was changed to ?? :: because larry wanted the single ? for more important uses. also doubling the ? made it more like , || which are related logical ops. and ?? as the oneshot regex match is totally out. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Mutating methods
Larry --
So, will mutatingness be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the end result is going to clobber the
current object, we could avoid making an extra copy.
I suppose there is some danger here. What if I write a class
that I intend to have value semantics. That is, once an instance's
value is set at construction time, it never changes, although you
can get new instances by invoking its methods. BigInt would
work this way. I can imagine a Point class working this way - you
don't (necessarily) want two objects hanging on to a point, and one
of them to mutate it into a different value out from under the other
one. You wouldn't expect that behavior from other value objects such
as built-in strings.
This points at mutatingness being aimed at the reference (variable)
not the referrent (value), unless it can be different in the case
of value-objects and container-objects...
So, if we had a BigDataContainer class for which it *was* reasonable
to mutate it in place, and we wanted that behavior to trigger on .=
to do an in-place modification:
$bigData .=applyBlockCipher($cipher, $key);
would there be a way to do that without the extra copy implied in:
$bigData = $bigData.applyBlockCipher($cipher, $key);
while leaving
$foo .=someOtherMethod();
equivalent to
$foo = $foo.someOtherMethod();
when $foo's class or someOtherMethod() implementation doesn't do
anything special?
Regards,
-- Gregor
On Wed, 2004-03-10 at 21:29, Larry Wall wrote:
On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
: I was thinking along the lines of...
:
: String $foo = hello;
: $foo.scramble!
That would be $foo.=scramble in the current scheme of things.
: print $foo\n;
: $foo = hello
: print $foo.scramble ~ \n;
: print $foo;
:
: OUTPUT (or close):
: elhlo
: hloel
: hello
:
: Also, along these same things.. is there a way to apply a method to all
: variables/objects of a certain type (e.g. String, Num, etc)? Taking the
: above example.. being able to write a method called Scramble that can be
: called as a method from any String type.
Two ways, actually. You can 'reopen the String class and add the method:
class String is extended {
method scramble () returns String {...}
}
or if you consider that underhanded, you can define a multi-sub:
multi sub *scramble (String $s) returns String {...}
If you call that as a method, and there is no ordinary scramble method,
it will fail soft to looking for a scramble multimethod, and end up
calling your definition. Or you can just call it directly as a function:
scramble(hello)
Larry
--
Gregor Purdy[EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
Re: Mutating methods
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();
Larry
Re: Mutating methods
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. 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.
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());
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...
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.
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?
So my guess is that it's probably better to have something more specific
for the mutator template. I think, actually, that I've convinced myself
that a mutator should be marked in its name, and that it should generally
be defined as a standard method rather than a multi sub:
method =sort (Array @ary is rw) {...} # inplace
This would automatically arrange to return the invocant.
It would be illegal to use Creturn in such a routine. And I guess,
since it's an ordinary method, we can leave out the invocant:
method =sort () {...} # inplace
with the assumption that the default invocant on a mutator would
automatically be assumed rw.
If you do happen to want to define a multi sub mutator, then the
syntax for calling it could be
«=sort»(@array)
However, we really don't have to special case the = prefix syntax if
we make it something like:
methodpostfix:.=sort () {...} # inplace
multi sub postfix:.=sort () {...} # inplace
That's getting way up there on the ugliness factor. Might be worth
a new operator category:
methodmutate:sort () {...} # inplace
multi sub mutate:sort () {...} # inplace
or
methodinplace:sort () {...} # inplace
multi sub inplace:sort () {...} # inplace
or
methodrw:sort () {...} # inplace
multi sub rw:sort () {...} # inplace
or
methodself:sort () {...} # inplace
multi sub self:sort () {...} # inplace
On the final hand, if people fall in love with both self:sort and =sort, we
could have =sort be a shorthand for self:sort where it's unambiguous.
On the (n+1)st hand, that says we could write it either as
@array.=sort.=uniq
or
Re: Mutating methods
On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote: On the final hand, if people fall in love with both self:sort and =sort, we could have =sort be a shorthand for self:sort where it's unambiguous. Wouldn't =sort potentially muck with POD? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Mutating methods
On Thu, Mar 11, 2004 at 02:05:55PM -0600, Jonathan Scott Duff wrote:
: On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
: On the final hand, if people fall in love with both self:sort and =sort, we
: could have =sort be a shorthand for self:sort where it's unambiguous.
:
: Wouldn't =sort potentially muck with POD?
Could. Historically pod only pays attention to = on the left margin though.
So you generally wouldn't have any problem unless you were in the habit
of declaring your methods in the C-ish idiom of:
int method
=rotate (int $a is rw) {...}
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. It interacts badly with global names anyway.
Is it *=sort or =*sort? With *self:sort it's more obvious.
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.
In that case, C»+=« is a double-meta operator that ends up generating
a hyper self:+.
I kinda like this approach because it means you can always get all of
$a !! $b
$a !!= $b
@a »!!« @b
@a »!!=« @b
merely by defining infix:!!. 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 non-associating binary operator that *should*
have an assignment operator? The basic definition of non-associating
seems to be that the type of the arguments is incompatible with the
type produced by the operator. Which is precisely the problem with
something like
$a cmp= $b
insofar as $a is being treated as a string at one moment and as a boolean
at the next.
Larry
Re: Mutating methods
On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote: : Which is precisely the problem with something like : : $a cmp= $b : : insofar as $a is being treated as a string at one moment and as a boolean : at the next. Well, okay, not a boolean. More like a troolean. Larry
Re: Mutating methods
On 3/11/04 4:04 PM, Larry Wall wrote: On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote: : Which is precisely the problem with something like : : $a cmp= $b : : insofar as $a is being treated as a string at one moment and as a boolean : at the next. Well, okay, not a boolean. More like a troolean. Back in my daaa, we used to call that a scalar. And we liked it, because it was all we had! ;) -John
Re: Mutating methods
On Thu, 2004-03-11 at 13:04, Larry Wall wrote: Well, okay, not a boolean. More like a troolean. Unless it's a falselean. -- c
Re: Mutating methods
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote: : On Thu, 2004-03-11 at 13:04, Larry Wall wrote: : : Well, okay, not a boolean. More like a troolean. : : Unless it's a falselean. It's more truelean than falselean by a 2/3rds majority. And it's much more if you include 2, -2, 3, -3,... in the data type. And it's *very* much more if you include the reals Larry
Re: Objects, init, and vtable limits
Dan Sugalski [EMAIL PROTECTED] wrote: Right now, we can create new PMCs by calling the class init method. It takes no parameters which somewhat limits the utility of the thing as a true initializer. Does it or not? newclass P1, Foo find_global P2, _init store_global Foo, __init, P2 find_type I1, Foo new P5, .PerlString set P5, hello\n new P3, I1 ... .pcc_sub _init: print init\n print P5 ... $ parrot o.pasm init hello leo
Re: [BUG] load_bytecode can print hello world
Jens Rieks [EMAIL PROTECTED] wrote: Hi, this time a funny bug :-) 2. create a file hello.imc with the following content: .emit .pcc_sub @LOAD _onload: print foo\n end ^^^ It's called as a PCC subroutine, so you have to return from it via invoke P1. I wrote that end is equivalent, but that's wrong. While end terminates the run loop, it does *not* restore the context, specifically, it does not restore the byte code segment (with the constant table inside) The code runs than on an arbitrary code position which happens to be a print statement with constant tables swapped (print_sc has an index into the constants) - or something like this, I didn't look further. jens leo
Re: Methods and IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: Calling a method: object.variable(pararms) object.literal name(params) Done. leo
Re: Namespaces in IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: While we still need to nail down the final bits of namespace stuff, I'm running into the need for it in IMCC code, so its time to finally deal with it. I don't really care what the syntax looks like, so I'm proposing: .namespace [foo; bar; baz] Done a bit: .namespace [ Foo ] .namespace [ Foo; Bar ] the latter is only in the parser currently (no deepere nesting yet). Do we want bare words too? leo
Re: Methods and IMCC
At 2:15 PM +0100 3/11/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Calling a method: object.variable(pararms) object.literal name(params) Done. Woohoo! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces in IMCC
At 2:14 PM +0100 3/11/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: While we still need to nail down the final bits of namespace stuff, I'm running into the need for it in IMCC code, so its time to finally deal with it. I don't really care what the syntax looks like, so I'm proposing: .namespace [foo; bar; baz] Done a bit: .namespace [ Foo ] .namespace [ Foo; Bar ] the latter is only in the parser currently (no deepere nesting yet). Cool. Do we want bare words too? No, I don't think so. I want to move away from bare words for namespaces as soon as we can--what's in now's just a hack/stopgap to get things moving. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Methods and IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: Method declarations: .pcc_sub foo prototyped, method .param pmc foo .param pmc bar .end That is, you add a method on the end of the sub declaration line. If you do so, the local self refers to the object pmc register. Done. .namespace [ Foo ] .sub _meth method print in meth\n isa $I0, self, Foo ... *If* a sub is declared as Cmethod, Cself is a valid identifier refering to CP2. leo
Dates. Or, rather, months
Okay, unless there are objections I'm going to rejig the date decoding logic to return months from 1-12, rather than 0-11. We already fix years, so it seems to make sense. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[BUG] can not call methods with self
Hi,
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()
jens
Index: t/pmc/object-meths.t
===
RCS file: /cvs/public/parrot/t/pmc/object-meths.t,v
retrieving revision 1.9
diff -u -w -r1.9 object-meths.t
--- t/pmc/object-meths.t 11 Mar 2004 13:17:21 - 1.9
+++ t/pmc/object-meths.t 11 Mar 2004 15:29:48 -
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 7;
+use Parrot::Test tests = 8;
use Test::More;
output_like('CODE', 'OUTPUT', callmethod - unknown);
@@ -180,4 +180,71 @@
bar_init
in sub
done
+OUTPUT
+
+output_is('CODE', 'OUTPUT', methods: self);
+##PIR##
+.sub _main
+.local pmc A
+.local pmc B
+
+newclass A, A
+newclass B, B
+
+find_type I0, A
+find_type I1, B
+
+new A, I0
+new B, I1
+
+setprop A, B, B
+
+A.foo()
+B.foo()
+
+end
+.end
+
+.namespace [A]
+
+.sub foo method
+.local pmc B
+
+self = P2
+print A::foo\n
+getprop B, B, self
+
+self.blah()
+B.blah()
+self.blah()
+
+.pcc_begin_return
+.pcc_end_return
+.end
+
+.sub blah method
+print A::blah\n
+.pcc_begin_return
+.pcc_end_return
+.end
+
+.namespace [B]
+
+.sub foo method
+print B::foo\n
+.pcc_begin_return
+.pcc_end_return
+.end
+
+.sub blah method
+print B::blah\n
+.pcc_begin_return
+.pcc_end_return
+.end
+CODE
+A::foo
+A::blah
+B::blah
+A::blah
+B::foo
OUTPUT
Re: [BUG] can not call methods with self
At 4:34 PM +0100 3/11/04, Jens Rieks wrote: Hi, 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() Before I go and apply this, could you sync and retry? I'm not seeing any test failures here, so there might be a crossing in the CVS. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Data::Dumper test version
Jens Rieks [EMAIL PROTECTED] wrote: Hi all, attached is an object orientated version of library/dumper.imc. (it needs libraray/objecthacks.imc from yesterday) Should that still get applied? Major object syntax improvements are now in. It should get much cleaner and simpler now. leo
Re: Namespaces in IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: While we still need to nail down the final bits of namespace stuff, I'm running into the need for it in IMCC code, so its time to finally deal with it. I don't really care what the syntax looks like, so I'm proposing: .namespace [foo; bar; baz] as a way to set the current namespace for subs to foo::bar::baz. I have now implemented the nested namespace too: .namespace [Foo;Bar] .pcc_sub __init: The label gets mangled to: _Foo::Bar::__init: and the nested namespaces are (hopefully) built correctly. But I can't test it. Nested namespaces aren't search yet. leo
Re: Data::Dumper test version
Hi, On Thursday 11 March 2004 16:31, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Hi all, attached is an object orientated version of library/dumper.imc. (it needs libraray/objecthacks.imc from yesterday) Should that still get applied? Major object syntax improvements are now in. It should get much cleaner and simpler now. No, not yet. I am converting the method calling to the new style at the moment... leo jens
RE: Dates. Or, rather, months
(YAY!) -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED] -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Thursday March 11, 2004 10:34 To: [EMAIL PROTECTED] Subject: Dates. Or, rather, months Okay, unless there are objections I'm going to rejig the date decoding logic to return months from 1-12, rather than 0-11. We already fix years, so it seems to make sense. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] can not call methods with self
Hi, On Thursday 11 March 2004 16:41, Dan Sugalski wrote: At 4:34 PM +0100 3/11/04, Jens Rieks wrote: Hi, 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() Before I go and apply this, could you sync and retry? I'm not seeing any test failures here, so there might be a crossing in the CVS. Its neither working on my computer nor on blao (tinderbox)... t/pmc/object-methsok 7/8# Failed test (t/pmc/object-meths.t at line 185) # got: 'error:imcc:parse error, unexpected '.', expecting '=' # # in file 't/pmc/object-meths_8.imc' line 32 # ' # expected: 'A::foo # A::blah # B::blah # A::blah # B::foo # ' # './parrot t/pmc/object-meths_8.imc' failed with exit code 1 # Looks like you failed 1 tests of 8. jens
RE: Dates. Or, rather, months
At 10:50 AM -0500 3/11/04, Gordon Henriksen wrote: (YAY!) Heh. And done, too. May cause issue with legacy code, but the libraries for the various languages can hide the correct behaviour with historically accurate incorrect behaviour. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Thursday March 11, 2004 10:34 To: [EMAIL PROTECTED] Subject: Dates. Or, rather, months Okay, unless there are objections I'm going to rejig the date decoding logic to return months from 1-12, rather than 0-11. We already fix years, so it seems to make sense. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] can not call methods with self
At 5:07 PM +0100 3/11/04, Jens Rieks wrote: Hi, On Thursday 11 March 2004 16:41, Dan Sugalski wrote: At 4:34 PM +0100 3/11/04, Jens Rieks wrote: Hi, 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() Before I go and apply this, could you sync and retry? I'm not seeing any test failures here, so there might be a crossing in the CVS. Its neither working on my computer nor on blao (tinderbox)... Gotcha. Test applied, then, and we'll see where we go from here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] can not call methods with self
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. One more bug was in the code: P2 wasn't preserved around method calls. Fixed too. jens Thanks for the test, leo
[BUG] assertion failed in src/packfile.c:2783
Hi, $ tar xzf err.tgz $ cd err $ ../parrot dumper_1.imc parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns pf-const_table-const_count' failed. aborted. It seems to be trigger by the empty __register sub in err/library/Data/Dumper/Default.imc The bug vanishes if one line of the sub is uncommented. jens err.tgz Description: application/tgz
[offtopic] Fwd: ScanMail Message: To Sender virus found or matched file blocking setting.
Hi, Am I the only one who receives this annoying message each time I send an .tgz attachment to the list? jens ---BeginMessage--- ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = [EMAIL PROTECTED] Recipient(s) = [EMAIL PROTECTED];[EMAIL PROTECTED] Subject = [BUG] assertion failed in src/packfile.c:2783 Scanning Time = 03/12/2004 04:43:19 Engine/Pattern = 6.860-1001/811 Action on message: The attachment err.tgz matched file blocking settings. ScanMail has taken the Deleted action. Warning to sender. Digital Picture's anti-virus software ScanMail detected a virus in an email attachment you sent to [EMAIL PROTECTED];[EMAIL PROTECTED] with the subject heading [BUG] assertion failed in src/packfile.c:2783. Both yourself and the recipient have been notified and the virus has either been removed or cleaned. ---End Message---
Re: [offtopic] Fwd: ScanMail Message: To Sender virus found or matched file blocking setting.
At Thu, 11 Mar 2004 19:00:18 +0100, Jens Rieks wrote: [1 text/plain; us-ascii (7bit)] Hi, Am I the only one who receives this annoying message each time I send an .tgz attachment to the list? You're the only one who has complained. I'll unsubscribe the offender. -R
[perl #27590] @LOAD with IMCC not always working correctly
# New Ticket Created by Jens Rieks
# Please include the string: [perl #27590]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27590
Hi,
the following patch adds 4 more tests to t/pmc/sub.t
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
(The patch also removes a redundant assignment of $temp)
jens
Index: t/pmc/sub.t
===
RCS file: /cvs/public/parrot/t/pmc/sub.t,v
retrieving revision 1.39
diff -u -w -r1.39 sub.t
--- t/pmc/sub.t 8 Mar 2004 00:20:09 - 1.39
+++ t/pmc/sub.t 11 Mar 2004 19:11:23 -
@@ -17,7 +17,7 @@
=cut
-use Parrot::Test tests = 66;
+use Parrot::Test tests = 70;
use Test::More;
use Parrot::Config;
@@ -769,7 +769,6 @@
ok
OUT
-$temp = temp.pasm;
open S, $temp or die Can't write $temp;
print S 'EOF';
.pcc_sub @LOAD _sub1:
@@ -790,6 +789,28 @@
back
OUTPUT
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+ .pcc_sub _error:
+ print error\n
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD second sub');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.pasm
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
system(.$PConfig{slash}parrot$PConfig{exe} -o temp.pbc $temp);
output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD in pbc');
@@ -1051,3 +1072,74 @@
unlink($temp, 'temp.pbc');
+$temp = temp.imc;
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD first sub - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub _foo:
+ print error\n
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD second sub - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub _foo:
+ print error\n
+ .pcc_sub _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode no @LOAD - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+back
+OUTPUT
+
+unlink($temp);
[perl #27590] @LOAD with IMCC not always working correctly
Hi,
the following patch adds 4 more tests to t/pmc/sub.t
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
(The patch also removes a redundant assignment of $temp)
jens
Index: t/pmc/sub.t
===
RCS file: /cvs/public/parrot/t/pmc/sub.t,v
retrieving revision 1.39
diff -u -w -r1.39 sub.t
--- t/pmc/sub.t 8 Mar 2004 00:20:09 - 1.39
+++ t/pmc/sub.t 11 Mar 2004 19:11:23 -
@@ -17,7 +17,7 @@
=cut
-use Parrot::Test tests = 66;
+use Parrot::Test tests = 70;
use Test::More;
use Parrot::Config;
@@ -769,7 +769,6 @@
ok
OUT
-$temp = temp.pasm;
open S, $temp or die Can't write $temp;
print S 'EOF';
.pcc_sub @LOAD _sub1:
@@ -790,6 +789,28 @@
back
OUTPUT
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+ .pcc_sub _error:
+ print error\n
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD second sub');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.pasm
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
system(.$PConfig{slash}parrot$PConfig{exe} -o temp.pbc $temp);
output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD in pbc');
@@ -1051,3 +1072,74 @@
unlink($temp, 'temp.pbc');
+$temp = temp.imc;
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD first sub - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub _foo:
+ print error\n
+ .pcc_sub @LOAD _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode @LOAD second sub - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+in sub1
+back
+OUTPUT
+
+open S, $temp or die Can't write $temp;
+print S 'EOF';
+.emit
+ .pcc_sub _foo:
+ print error\n
+ .pcc_sub _sub1:
+ print in sub1\n
+ invoke P1
+.eom
+EOF
+close S;
+
+output_is('CODE', 'OUTPUT', 'load_bytecode no @LOAD - imc');
+.pcc_sub _main:
+print main\n
+load_bytecode temp.imc
+print back\n
+end
+CODE
+main
+back
+OUTPUT
+
+unlink($temp);
[BUG] src/hash.c:256: promote_hash_key: Assertion `key' failed.
Hi, $ 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) jens err2.tgz Description: application/tgz
ponie unwell without --gc=libc
If the current ponie in CVS is built with full defaults for parrot, then
it fails to build Unicode::Normalize, and fails about 40 regression tests.
If parrot's garbage collector is changed from the default (compacting, IIRC)
to the either libc or malloc, then ponie only fails 6 tests. ie make this
change:
Index: Configure.pl
===
RCS file: /cvs/public/ponie/Configure.pl,v
retrieving revision 1.12
diff -r1.12 Configure.pl
47c47,48
system($^X,'Configure.pl',--ccflags= :add{ -I$dir/perl}) die error;
---
system($^X,'Configure.pl', --gc=libc,
--ccflags= :add{ -I$dir/perl}) die error;
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. Chatting with Dan
on IRC we think that it has to be a bug in parrot's GC.
Unfortunately Arthur and I can't get it down to a simple test case. For
example on x86 Linux t/op/pat fails at test 345 with parrot's default gc,
but that whole test passes with gc=libc. Trying to cut down the regression
tests to the fail point makes them pass, which suggests that it's the
cumulative resource usage that is really the problem, not any particular
perl construction. [tests fail in different places on OS X. Not tried other
systems yet. Still fighting AIX]
We're not sure how to track this one down further - at the moment the best
plan seems to be to apply the above patch to ponie, and make a snapshot
release with it in.
I've attached the diff between TEST run for the two configurations.
Nicholas Clark
--- logTESTdefault Thu Mar 11 16:13:51 2004
+++ logTESTgc=libc Thu Mar 11 15:22:48 2004
@@ -138,7 +138,7 @@
t/op/ord.ok
t/op/overrideok
t/op/packok
-t/op/pat.FAILED at test 345
+t/op/pat.ok
t/op/pos.ok
t/op/pow.ok
t/op/pushok
@@ -150,13 +150,10 @@
t/op/readok
t/op/readdir.ok
t/op/readlineok
-t/op/recurse.# Failed at op/recurse.t line 132
-# got '35584'
-# expected '0'
-FAILED at test 28
+t/op/recurse.ok
t/op/ref.ok
-t/op/regexp..FAILED at test 673
-t/op/regexp_noampFAILED at test 678
+t/op/regexp..ok
+t/op/regexp_noampok
t/op/regmesg.ok
t/op/repeat..ok
t/op/reverse.ok
@@ -191,7 +188,7 @@
t/op/ver.ok
t/op/wantarray...ok
t/op/write...ok
-t/uni/fold...FAILED at test 397
+t/uni/fold...ok
t/uni/lower..ok
t/uni/sprintfok
t/uni/title..ok
@@ -325,7 +322,7 @@
ext/Safe/t/safe1.ok
ext/Safe/t/safe2.ok
ext/Safe/t/safe3.ok
-ext/Safe/t/safeops...FAILED at test 108
+ext/Safe/t/safeops...ok
ext/SDBM_File/t/sdbm.ok
ext/Socket/t/socketpair..Something unexpectedly hung during testing at
../ext/Socket/t/socketpair.t line 39.
ok
@@ -339,10 +336,10 @@
ext/Storable/t/downgrade.ok
ext/Storable/t/forgive...ok
ext/Storable/t/freezeok
-ext/Storable/t/integer...FAILED at test 454
+ext/Storable/t/integer...ok
ext/Storable/t/interwork56...skipping test on this platform
ext/Storable/t/lock..ok
-ext/Storable/t/maliceFAILED at test 234
+ext/Storable/t/maliceok
ext/Storable/t/overload..ok
ext/Storable/t/recurse...ok
ext/Storable/t/restrict..ok
@@ -377,15 +374,9 @@
ext/threads/t/stress_string..skipping test on this platform
ext/threads/t/thread.skipping test on this platform
ext/Time/HiRes/t/HiRes...ok
-ext/Unicode/Normalize/t/func.Can't locate Unicode/Normalize.pm in @INC (@INC
contains: ../lib) at ../ext/Unicode/Normalize/t/func.t line 23.
-BEGIN failed--compilation aborted at ../ext/Unicode/Normalize/t/func.t line 23.
-FAILED at test 1
-ext/Unicode/Normalize/t/norm.Can't locate Unicode/Normalize.pm in @INC (@INC
contains: ../lib) at ../ext/Unicode/Normalize/t/norm.t line 23.
-BEGIN failed--compilation aborted at ../ext/Unicode/Normalize/t/norm.t line 23.
-FAILED at test 1
-ext/Unicode/Normalize/t/test.Can't locate Unicode/Normalize.pm in @INC (@INC
contains: ../lib) at
Re: [BUG] src/hash.c:256: promote_hash_key: Assertion `key' failed.
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, as noted in PDD15 (but not, I now see, in the inline documentation). Quite why you get such an uninformative error message I'm not sure. NB. The same holds true for callmethodcc STRING and both forms of the tailcallmethod ops. Simon
Re: ponie unwell without --gc=libc
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? 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. leo
newbie question....
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? What are the criteria for adding/deleting them? Thanks, Matt
Re: parrotbug working...
But what should those addresses do when receiving a message? - parrotbug: should open a RT ticket? Yes. This is the new equivalent of bugs-parrot at rt.perl.org. Use of that address should be phased out in favor of the new one. - status-ok: ? - status-nok: should open a RT ticket? Right now both of these email addresses get dumped into files. We need a new system (sigh) for processing these. It's a very simple perl and database thing. We'll want to use it for perl5 and parrot. (I wonder if we can just use CPAN testers for this? http://testers.cpan.org/show/parrot.html) Anyone (Robert? :-) ) knows what [EMAIL PROTECTED] do? A little too well. -R
Re: newbie question....
Matt Greenwood wrote: 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? Let me try as another newbie... ;-) Since the opcodes of parrot are not directly supported by any existing hardware, at least not now ;-), they have to be mapped to native code during execution. This costs something per parrot-operation. So if there are many different opcodes in parrot with powerful functionality behind them, this overhead does not hurt so much, because a parrot instruction gets a lot of stuff done. At least I heard this kind of explanation for Perl5, which uses something slightly like parrot internally as well. Maybe this reduces the answer by the real experts to a yes/no? ;-) Best regards, Karl
Re: Mutating methods
Larry Wall wrote:
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.
It's more truelean than falselean by a 2/3rds majority. And it's
much more if you include 2, -2, 3, -3,... in the data type. And it's
*very* much more if you include the reals
So that's a (numeric) scalar then...
I'm new to this list, although I've been keeping an eye on Perl 6 for
quite a while now as it's looking like it's going to be an extremely
pleasant language to work with. Seems I joined at the right time as
well, for these mutators are an interesting thing. Please excuse my no
doubt numerous abuses of conventional formatting used here as I don't
know it yet, and I've got a very shaky knowledge of some parts of the
Perl 6 grammar that everyone posting seems to know.
However, it strikes me that notation like
int method =foo(String $bar) {...}
is at risk of causing serious confusion to people coming from other
languages. This may not be a concern, of course (and isn't really one of
mine despite being a C++/Perl 5/Haskell kind of person at the moment).
It seems that
int method self:foo(String $bar) {...}
is clearer and easier to read, but I did actually prefer
int method mutate:foo(String $bar) {...}
or
int method inplace:foo(String $bar) {...}
which seem to have been dismissed in favour of the form using Cself,
although I can see that it does have a valid interpretation. Perhaps I'm
just too stuck in writing member subs of objects in Perl 5 by saying
sub foo {
my $self = shift;
# something useful here
}
so I always see 'self' as reading something like 'this' does in C++ or
Java (or as 'self' does in Python, if I'm remembering that correctly).
There is undeniable logic in using it to define mutators though, as they
do most certainly act upon 'self' or 'this' or whatever it's called.
One is lead to wonder if the most appropriate definition might not be
int method mutator:foo(String $bar) { ... }
but that's getting very silly, so maybe just ignore everything I said
just now and cheer the introduction of Cself as the most practical and
least prone to the introduction of finger trouble.
And having said all that, I like .= as invocation syntax for it, even if
I keep thinking it means 'append string'.
Anyway, thankyou for listening, I shall return now to watching in awe.
Matthew
Re: Mutating methods
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.
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.
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 non-associating binary operator that *should*
have an assignment operator? The basic definition of non-associating
seems to be that the type of the arguments is incompatible with the
type produced by the operator. Which is precisely the problem with
something like
$a cmp= $b
insofar as $a is being treated as a string at one moment and as a boolean
at the next.
I think it's merely a philosophical problem.
After all, we don't complain when people write:
$a = $a cmp $b;
So should we complain when people write exactly the same thing, only as:
$a cmp= $b;
Stylistically, they're equally as abhorrent, but Perl users aren't expecting
the Stylish Inquisition.
The real question is whether the two forms are equally likely to indicate a
logic error. One could argue that anyone who writes the first is more likely
just being (small-l) lazy, whereas writing the second probably indicates a
thinko. But then one could also argue that it's (small-l) lazier to write
the second than the first, so the second is actually *more* likely to be
(small-l) laziness than error.
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?
Damian
