[pypy-dev] Blocked Block error

[Ryan Gonzalez]

Thank you so much again! That makes sense!


On Tue, Apr 22, 2014 at 3:14 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Ryan,
>
> On 21 April 2014 20:37, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> > 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.
>
> 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.
>



-- 
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20140422/3748d2ff/attachment.html>