Re: [perl #17739] [PATCH] Tests for assign ops
At 10:35 PM +0100 10/4/02, Nicholas Clark wrote: >I don't feel qualified to apply various of the outstanding patches, for both >the above reasons. > >use more 'executive dictatorial decisions'; Working on that--give us a day or three. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17739] [PATCH] Tests for assign ops
Nicholas Clark wrote: > I don't feel qualified to apply various of the outstanding patches, for both > the above reasons. > > use more 'executive dictatorial decisions'; Can't locate more.pm in @INC (@INC contains: [EMAIL PROTECTED] http://www.parrotcode.org/ .). > Nicholas Clark AOL && SCNR leo
Re: [perl #17739] [PATCH] Tests for assign ops
On Thu, Oct 03, 2002 at 08:02:59PM +, Simon Glover wrote: > # New Ticket Created by Simon Glover > # Please include the string: [perl #17739] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17739 > > > > > Patch below adds tests for assign_p_i, assign_p_n and assign_p_s. > (There's no test for assign_p_p because the scalar PMCs don't support > it yet). Thanks, applied. But the bug isn't marked as such because I've not yet worked out how to do that. I like tests. They can (usually) be applied without having to wonder about whether the change they represent has design implications. Or actually having to understand that much of the code base (which I really don't at the moment) I don't feel qualified to apply various of the outstanding patches, for both the above reasons. use more 'executive dictatorial decisions'; Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
RE: [perl #17739] [PATCH] Tests for assign ops
> -Original Message- > From: Peter Gibbs [mailto:[EMAIL PROTECTED]] > [snip] > An interesting question, not discussed when the change was > initiated, relates to property assignments eg > new P0, .PerlArray > set P0, 6 > This most certainly does not set register P0 to six, so the 'set' > opcode should not apply, but it is also not really an assignment > either. Any thoughts? there is a similar problem with subs new P0, .Sub set P0, I guess the problem is that set is being used for too much? This is the way I thought things were headed: set_x_x just moves a pointer or a value, possibly needing a cast, copy or conversion $1 = $2; $1 = string_from_num($2); etc While assign_p_x calls the appropriate vtable method $1->vtable->set_pmc(interpreter, $1, $2); $1->vtable->set_integer_native(interpreter, $1, $2); etc The above .Sub and .PerlArray examples could be handled with op new(out PMC, in INT, in PMC) op new(out PMC, in INT, in INT) etc instead of the set op. I think this separation could be more clear, but I suppose this leaves some cases out. So maybe a set_property op? Though some things could be left to _methods_ instead of ops. -- Jonathan Sillito > > The primary goal of the exercise was to be able to distinguish > between 'set P0, P1' which simply sets the P0 register equal to > the P1 register, and 'assign P0, P1' which would, somehow, > cause the existing PMC referenced by P0 to acquire the value > of the PMC referenced by P1 (via the vtable method set_pmc). > How to achieve this has never been resolved. The changes of > the other 'set P0, xxx' opcodes to 'assign' are basically for > consistency. > -- > Peter Gibbs > EmKel Systems >
Re: [perl #17739] [PATCH] Tests for assign ops
Jonathan Sillito wrote: > So does that mean, the only set ops will be those that take two registers of > the same type? > > set_p_p > set_i_i > set_s_s > set_n_n Anything with a destination register type other than P will remain 'set', as the contents of the register itself are being changed (e.g. set_i_ic, set_n_i) (This is of course based on my interpretation of Dan's original posting) An interesting question, not discussed when the change was initiated, relates to property assignments eg new P0, .PerlArray set P0, 6 This most certainly does not set register P0 to six, so the 'set' opcode should not apply, but it is also not really an assignment either. Any thoughts? The primary goal of the exercise was to be able to distinguish between 'set P0, P1' which simply sets the P0 register equal to the P1 register, and 'assign P0, P1' which would, somehow, cause the existing PMC referenced by P0 to acquire the value of the PMC referenced by P1 (via the vtable method set_pmc). How to achieve this has never been resolved. The changes of the other 'set P0, xxx' opcodes to 'assign' are basically for consistency. -- Peter Gibbs EmKel Systems
RE: [perl #17739] [PATCH] Tests for assign ops
So does that mean, the only set ops will be those that take two registers of
the same type?
set_p_p
set_i_i
set_s_s
set_n_n
--
Jonathan Sillito
(who is willing to help with the migration)
> -Original Message-
> From: Peter Gibbs [mailto:[EMAIL PROTECTED]]
> Sent: October 3, 2002 11:43 PM
> To: Leopold Toetsch; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [perl #17739] [PATCH] Tests for assign ops
>
>
> Leopold Toetsch wrote:
> > Nothing against the tests - it's always a good thing to have
> tests - but
> > I'm confused:
> >
> > inline op set(inout PMC, in INT) {
> >$1->vtable->set_integer_native(interpreter, $1, $2);
> >goto NEXT();
> > }
> > inline op assign(inout PMC, in INT) {
> >$1->vtable->set_integer_native(interpreter, $1, $2);
> >goto NEXT();
> > }
> >
> > and so on.
> >
> > So what is the _difference_ between set and assign?
>
> The 'assign' opcodes were intended to replace 'set' for the
> situations where the value of a PMC was being updated,
> rather than the PMC register being changed.
> There are a lot of changes needed to existing code (e.g.
> most of the tests) before the 'set' versions can be deleted.
> --
> Peter Gibbs
> EmKel Systems
>
>
Re: [perl #17739] [PATCH] Tests for assign ops
Leopold Toetsch wrote:
> Nothing against the tests - it's always a good thing to have tests - but
> I'm confused:
>
> inline op set(inout PMC, in INT) {
>$1->vtable->set_integer_native(interpreter, $1, $2);
>goto NEXT();
> }
> inline op assign(inout PMC, in INT) {
>$1->vtable->set_integer_native(interpreter, $1, $2);
>goto NEXT();
> }
>
> and so on.
>
> So what is the _difference_ between set and assign?
The 'assign' opcodes were intended to replace 'set' for the
situations where the value of a PMC was being updated,
rather than the PMC register being changed.
There are a lot of changes needed to existing code (e.g.
most of the tests) before the 'set' versions can be deleted.
--
Peter Gibbs
EmKel Systems
Re: [perl #17739] [PATCH] Tests for assign ops
Simon Glover (via RT) wrote:
> Patch below adds tests for assign_p_i, assign_p_n and assign_p_s.
> (There's no test for assign_p_p because the scalar PMCs don't support
> it yet).
Nothing against the tests - it's always a good thing to have tests - but
I'm confused:
inline op set(inout PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1, $2);
goto NEXT();
}
inline op assign(inout PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1, $2);
goto NEXT();
}
and so on.
So what is the _difference_ between set and assign?
leo
