Ticket #681 (closed bug: fixed)

Opened 13 years ago

Last modified 12 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 13 years ago.
Failing example of IO object in PIR
tt_681_fix.patch Download (0.6 KB) - added by whiteknight 13 years ago.
a patch that fixes this particular issue, but doesn't allow IO objects to be defined in PIR generally

Change History

Changed 13 years ago by flh

Failing example of IO object in PIR

  Changed 13 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 13 years ago by whiteknight

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

follow-up: ↓ 4   Changed 13 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 13 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 12 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 12 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.