Cannot use a PIR object for IO

[flh]

I cannot define a class in PIR which I can use for IO operations (e.g., whose 'read' method would be called by the read opcode).

See for example the attached code, which creates a "MyIO", whose "read" method always returns the string "foo". Yet, calling the "read" opcode with a MyIO object as argument just returns the empty string.

[flh]

Failing example of IO object in PIR

[flh]

By the way, Parrot does try to call the "read" method, since it complains with a "Method 'read' not found" when this method doesn't exist.

[whiteknight]

Okay, I've figured out the problem. I'm sorry that it's taken me so long to do it! The problem, in a nutshell, is that the IO system currently uses Parrot_PCCINVOKE to perform the sub call instead of calling the more versatile Parrot_invoke_from_sig_object() family of functions. Parrot_PCCINVOKE is designed to run methods which are written in C, not methods which are written in PIR. You can see around line src/call/pcc.c:2870 that Parrot_PCCINVOKE calls the invoke vtable method on the Sub PMC, but never calls runops. For NCI subs, invoke executes the function directly. However, for PIR-defined Subs, it only sets up the execution environment for later execution by the current runcore (if we're using the invokecc opcode) or from the runops* family of functions.

The short answer is that if we switch the call in Parrot_io_reads from Parrot_PCCINVOKE to Parrot_pcc_invoke_method_from_c_args, the example code you posted magically works. I'm attaching a patch to that affect in a moment.

The long answer is that this function is considered "experimental", and it likely won't work perfectly until Allison's pcc_rewiring branch gets merged into trunk. In fact, I can tell you for certain that if we switch over all the calls in src/io/api.c, it will cause unexplained segfaults and test failures, so most of the API functions cannot be used with PIR-defined objects. Since Allison is converting all the Parrot_PCCINVOKE calls as part of her branch work, this ticket should be resolved as soon as she merges.

[whiteknight]

a patch that fixes this particular issue, but doesn't allow IO objects to be defined in PIR generally

[jkeenan]

Replying to whiteknight:

The long answer is that this function is considered "experimental", 
and it likely won't work perfectly until Allison's pcc_rewiring branch 
gets merged into trunk. In fact, I can tell you for certain that if we 
switch over all the calls in src/io/api.c, it will cause unexplained 
segfaults and test failures, so most of the API functions cannot be 
used with PIR-defined objects. Since Allison is converting all the 
Parrot_PCCINVOKE calls as part of her branch work, this ticket should 
be resolved as soon as she merges.

Whiteknight, Allison:

Did the branch work described here resolve the issues in this ticket?

Thank you very much.

kid51

[whiteknight]

The attached test file executes perfectly on my system. This issue is resolved.