First, a quick apology: I don't want anyone to feel like I'm abusing the list or something. I just really need help, and StackOverflow isn't necessarily RPython-friendly. What I want to know is the meaning of the Blocked Block error. I always get that error at least once. Usually I can solve it myself, but I'm curious as to what it actually means. -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
Hi Ryan, On 21 April 2014 20:37, Ryan Gonzalez <rymg19@gmail.com> wrote:
When RPython does type inference, it works incrementally. There are often some operations that don't seem to make sense temporarily, but this problem will be resolved by the type inference done on other parts of the same program. The typical example is "x = foo.attr" where, as far as we know, the instance "foo" has no attribute "attr". This looks like an error, but often isn't: if we continue somewhere else, we'll see "foo.attr = 42" and then know that "foo" really has an "attr". "Blocked Blocks" errors are raised if at the end of the type inference process there are still such unresolved positions left. If several errors are printed, often only one of them is relevant (e.g. a real typo). The error can also occur becuse the particular type inference done can prove that "foo" is always None in this case, so that reading "foo.attr" doesn't make sense. That can be annoying when running tests that only try to translate a part of the program. It's usually easy to find a workaround, e.g. by inserting "assert foo is not None". Unlike "x = foo.attr", which blocks, an assert that always fails does not create a blocked block, but will simply always raise AssertionError in the translated program. (The distinction is a bit artificial. We could also never create blocked blocks and simply raise AssertionErrors if this point is executed, but that seems like a bad idea in general...) A bientôt, Armin.
Thank you so much again! That makes sense! On Tue, Apr 22, 2014 at 3:14 AM, Armin Rigo <arigo@tunes.org> wrote:
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
Hi Ryan, On 21 April 2014 20:37, Ryan Gonzalez <rymg19@gmail.com> wrote:
When RPython does type inference, it works incrementally. There are often some operations that don't seem to make sense temporarily, but this problem will be resolved by the type inference done on other parts of the same program. The typical example is "x = foo.attr" where, as far as we know, the instance "foo" has no attribute "attr". This looks like an error, but often isn't: if we continue somewhere else, we'll see "foo.attr = 42" and then know that "foo" really has an "attr". "Blocked Blocks" errors are raised if at the end of the type inference process there are still such unresolved positions left. If several errors are printed, often only one of them is relevant (e.g. a real typo). The error can also occur becuse the particular type inference done can prove that "foo" is always None in this case, so that reading "foo.attr" doesn't make sense. That can be annoying when running tests that only try to translate a part of the program. It's usually easy to find a workaround, e.g. by inserting "assert foo is not None". Unlike "x = foo.attr", which blocks, an assert that always fails does not create a blocked block, but will simply always raise AssertionError in the translated program. (The distinction is a bit artificial. We could also never create blocked blocks and simply raise AssertionErrors if this point is executed, but that seems like a bad idea in general...) A bientôt, Armin.
Thank you so much again! That makes sense! On Tue, Apr 22, 2014 at 3:14 AM, Armin Rigo <arigo@tunes.org> wrote:
-- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
participants (2)
-
Armin Rigo -
Ryan Gonzalez