This contains a test to prove that Parrot_api_get_compiler is unreliable #780

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
5 participants
Contributor

bdw commented Jun 4, 2012

The return value of Parrot_api_get_compiler is unreliable (i.e. allways returns 1). This test proves that. Maybe compreg should raise an error?

Member

Benabik commented Jun 4, 2012

I think you have to use imcc_get_pir_compreg_api(interp, 1, &pir_compiler) (where pir_compiler is a Parrot_PMC) before compreg 'PIR' will work. Check out setup_imcc() in frontend/parrot2/main.c:191

Contributor

bdw commented Jun 4, 2012

Thats very true but not the point.
The point is that Parrot_api_get_compiler returns true for /all/ calls, irrespective of whether I put in a reasonable name or garbage. Personally, I think not finding a compiler should be a failure case.

Contributor

Whiteknight commented Jun 4, 2012

The return value of API calls indicates whether the operation in question completed normally or abnormally (an unhandled exception was thrown). If the return value is 0, that means there is an unhandled exception stored in the interpreter to be examined and possibly reported to the user.

Neither of the compreg get/set pathways throw exceptions, so we would expect this API to always return 1. In the future if we use a different mechanism that throws exceptions, we might expect this behavior to change.

The Parrot_api_get_compiler routine returns a PMCNULL in an out parameter if the compiler is not found. You can inspect that value to determine if a compiler has been found.

That said, the current behavior is sane and consistent with the rest of the API. The case can be made that a user can legitimately register PMCNULL to the compreg hash, and this creates a semipredicate problem. The argument can be made that the more useful behavior might be for Parrot_api_get_compreg to throw an exception if a compiler is not found, instead of returning PMCNULL.

In the absence of thrown exceptions, the current behavior is "correct"

Contributor

bdw commented Jun 4, 2012

I understand that this is not a bug per se. But from the point of view of an API user, not having found a compiler is a failure. The result of Parrot_api_get_compiler is useless as the function will never fail. In fact, having to check for the return value being NULL aside from having to check the return value is redundant.
It could probably be resolved by throwing an exception inside the API function. That way, existing code (that does not expect compreg to fail) will continue to work, and the API will do what the user expects.

Contributor

zhuomingliang commented Jun 13, 2012

Whiteknight, how about this pull request?

Contributor

Whiteknight commented Jun 13, 2012

I am +1 to merging this, but it does not appear mergable. I've tried twice and it doesn't seem like I can merge it (or merging brings no changes). Can somebody please verify?

Contributor

bdw commented Jun 13, 2012

Oh, that is really very probably my fault.
I have reset the repository in the meantime
I'm going to see if I can get it back.

2012/6/13 Andrew Whitworth
reply@reply.github.com:

I am +1 to merging this, but it does not appear mergable. I've tried twice and it doesn't seem like I can merge it (or merging brings no changes). Can somebody please verify?


Reply to this email directly or view it on GitHub:
#780 (comment)

Contributor

bdw commented Jun 13, 2012

Oh, that is my fault. I have erased the repository only to start again with a new one.
I still have the files locally, and I can push a new branch if needed. But that does mean a new pull request.
Also, I should add imcc_get_pir_compiler to the test first.

leto closed this Oct 30, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment