Jonathan Worthington wrote:
I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?
'morph' was added specifically for the Perl 5 behavior of changing types
when assigned to. But really, a more accurate representa
On Sat, Jan 17, 2009 at 2:12 PM, chromatic wrote:
> I haven't been awake long, but could internal code call whatever the copy
> opcode calls?
I guess I don't know what people are talking about here with copy.
But, I would be hesitant to remove morph in order to rely on some
sideeffect of a differ
From: Jonathan Worthington
Date: Sat, 17 Jan 2009 17:11:23 +0100
I'm curious - is anyone else doing a HLL on Parrot that uses morph?
Not me.
-- Bob Rogers
http://www.rgrjr.com/
On Saturday 17 January 2009 10:36:13 Andrew Whitworth wrote:
> Even if the morph opcode isn't used often, the morph VTABLE interface
> is used quite a bit internally. There really isn't any easier and
> still standard way of changing between types for PMCs. It certainly
> beats having to invoke PM
> On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington
>> I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
>> nobody is, is it worth spending time on, or even worth keeping?
>>
>> Thanks,
>>
>> Jonathan
>>
Even if the morph opcode isn't used often, the morph VTABLE interfac
On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington
wrote:
> Patrick R. Michaud wrote:
>> Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
>> morph any longer.
> This is true AFAIK too.
>
>> We now have the 'copy' opcode to do what the "morph workaround" was doing
>> (and I don't
Patrick R. Michaud wrote:
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer.
This is true AFAIK too.
We now have the 'copy' opcode to do what the "morph workaround" was doing (and
I don't think copy is using VTABLE_morph).
IIRC, copy once used to, but stopp
Patrick R. Michaud wrote:
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer. We now have the 'copy' opcode to do what the
"morph workaround" was doing (and I don't think copy is using
VTABLE_morph).
We've been ripping out morph in all the core PMCs too. So, I'm
On Fri, Jan 16, 2009 at 11:34:05PM -0800, Allison Randal wrote:
>
> Not a string, a PMC (like Coke said). String type names are almost as
> bad as type IDs. And check the performance on the branch, as I'm not
> sure how heavily PGE is using morph. We may need both integer and PMC
> versions of
Andrew Whitworth via RT wrote:
Okay, I did some work on this last night, and here's the current status.
1) Modified the behavior of the "morph" PIR override so that it takes a
string in trunk. We previously weren't able to override this method at
all, so nobody is used to the "old way" at the P
On Thu, Jan 15, 2009 at 6:32 PM, Andrew Whitworth via RT <
parrotbug-follo...@parrotcode.org> wrote:
> Okay, I've committed a variant of my patch in r35599, but I've run into
> some issues while trying to test this. The morph VTABLE interface takes
> an INTVAL which represents the PMC type to morp
On Thu, Jan 15, 2009 at 1:32 PM, Andrew Whitworth via RT
wrote:
> Okay, I've committed a variant of my patch in r35599, but I've run into
> some issues while trying to test this. The morph VTABLE interface takes
> an INTVAL which represents the PMC type to morph to. This is the value
> that's pass
12 matches
Mail list logo
