[perl #41511] Parrot_call_sub* Incompatible with Multisubs

[Chromatic]

# New Ticket Created by chromatic
# Please include the string: [perl #41511]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41511 >

Hi there,

Here's a complex one. Define a multisub in PIR, then try to call it from C.
I assume that you get the PMC for the (multi) sub, then use
Parrot_call_sub*() to invoke it.

The problem is that the layout of a Sub PMC is different from the layout of a
MultiSub PMC, especially when the code tries to do:

CONTEXT(interp->ctx)->constants =
PMC_sub(sub)->seg->const_table->constants;

For a normal Sub, PMC_sub(sub)->seg is a pointer. For a MultiSub,
PMC_sub(sub)->seg is the number of multi variants. Crash! Boom!

Removing this code doesn't help, because then it gives argument mismatch
errors. Similarly, setting this code within invoke() in MultiSub doesn't
seem to avoid the crash either for some reason.

I suspect that there was a similar problem avoided earlier when MultiSubs
first appeared, or that there's a better way to initialize context when
running code from C.

I can provide more code if necessary, unless this looks like an obvious fix to
someone.

-- c

[Matt Diephouse]

If you wanted to send me some sample code that invoked both a normal sub and
a MultiSub, I'd certainly take a look. I'm pretty sure the whole idea of
invoke-able objects was never really thought out -- some of the logic in
Sub.invoke() should be elsewhere.

--
Matt Diephouse
http://matt.diephouse.com

[Chromatic]

On Thursday 15 February 2007 08:24, Matt Diephouse wrote:

> If you wanted to send me some sample code that invoked both a normal sub
> and a MultiSub, I'd certainly take a look. I'm pretty sure the whole idea
> of invoke-able objects was never really thought out -- some of the logic in
> Sub.invoke() should be elsewhere.

Committed as a TODO test in t/src/extend.t in r17034.

Good luck,
-- c

[James Keenan via RT]

Matt, chromatic:

This test is still in TODO status as of r26404. Can you provide us with
an update as to the ticket's status?

Thank you very much.
kid51

[Matt Diephouse via RT]

On Sun Mar 16 10:57:07 2008, jk...@verizon.net wrote:
> Matt, chromatic:
>
> This test is still in TODO status as of r26404. Can you provide us with
> an update as to the ticket's status?
>
> Thank you very much.
> kid51

Sure. I investigated the issue a while back, and the whole thing is basically stalled. The code
surrounding the issue (the packfile code) is a bit of a mess, which made finding a real fix
difficult. I started to work on refactoring that code in order to find a fix here, but it's large,
hairy, and difficult to work with. This bug should either remain open or be changed to
stalled.

To recap, I think this bug will require a substantial refactoring and cleanup of the packfile
code. For now, I believe it's a non-trivial bug (except, perhaps, for someone with a more
thorough understanding of the packfile code).

My involvement with Parrot has been minimal as of late, but I'm willing to retain ownership of
the ticket and fix the issue if packfile code gets cleaned up.

--
Matt Diephouse

[Chromatic]

On Sunday 16 March 2008 12:16:06 Matt Diephouse via RT wrote:

> Sure. I investigated the issue a while back, and the whole thing is
> basically stalled. The code surrounding the issue (the packfile code) is a
> bit of a mess, which made finding a real fix difficult. I started to work
> on refactoring that code in order to find a fix here, but it's large,
> hairy, and difficult to work with. This bug should either remain open or be
> changed to stalled.
>
> To recap, I think this bug will require a substantial refactoring and
> cleanup of the packfile code. For now, I believe it's a non-trivial bug
> (except, perhaps, for someone with a more thorough understanding of the
> packfile code).

Agreed.

> My involvement with Parrot has been minimal as of late, but I'm willing to
> retain ownership of the ticket and fix the issue if packfile code gets
> cleaned up.

I believe Jonathan was looking into this. In particular, adding arity to Subs
was the first step.

-- c

[Jonathan Worthington]

chromatic wrote:
>> To recap, I think this bug will require a substantial refactoring and
>> cleanup of the packfile code. For now, I believe it's a non-trivial bug
>> (except, perhaps, for someone with a more thorough understanding of the
>> packfile code).
>>
> Agreed.
>

Same here.

> I believe Jonathan was looking into this. In particular, adding arity to Subs was the first step.
>

Also, I already added inspect, which provides a way to get a bit more
than the arity, including the numbers of different types of parameters.
I can extend that further as needed.

On the more general packfile code re-factoring, yes, I still plan to do
it. I was somewhat distracted from Parrot guts by Rakudo during Feb,
when I was trying to help get it more featureful for when I was
presenting it at a couple of conferences, and so far this month have
been busy doing $DAYJOB to pay the bills. Things should ease up a bit soon.

Thanks,

Jonathan