Ticket #681 (closed bug: fixed)

Opened 6 years ago

Last modified 5 years ago

Cannot use a PIR object for IO

Reported by: flh Owned by: whiteknight
Priority: normal Milestone:
Component: core Version: trunk
Severity: medium Keywords:
Cc: allison Language:
Patch status: Platform:

Description

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.

Attachments

test.pir Download (417 bytes) - added by flh 6 years ago.
Failing example of IO object in PIR
tt_681_fix.patch Download (0.6 KB) - added by whiteknight 6 years ago.
a patch that fixes this particular issue, but doesn't allow IO objects to be defined in PIR generally

Change History

Changed 6 years ago by flh

Failing example of IO object in PIR

  Changed 6 years ago by 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.

  Changed 6 years ago by whiteknight

  • status changed from new to assigned
  • owner set to whiteknight

follow-up: ↓ 4   Changed 6 years ago by 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.

Changed 6 years ago by whiteknight

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

in reply to: ↑ 3   Changed 5 years ago by jkeenan

  • cc allison added
  • component changed from none to core

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

  Changed 5 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.