[patch][python] 5 of 5 - Frame filter documentation changes
Phil Muldoon
pmuldoon@redhat.com
Fri Apr 19 14:24:00 GMT 2013
> FrameDecorator also stores this in an attribute, "base".
> Should that attribute just be declared public?
> And if not, shouldn't it be renamed to start with a "_"?
>
> Phil> + def function(self):
> Phil> + frame = self.inferior_frame()
> Phil> + name = str(frame.name())
> Phil> + function = str(frame.function())
> Phil> +
> Phil> + if frame.type() == gdb.INLINE_FRAME:
> Phil> + name = name + " [inlined from "+ function +"]"
>
> This actually violates the FrameDecorator guidelines, since it bypasses
> self.base to get the name from the inferior_frame.
>
> It seems like it should call self.base.name() instead.
> And, it should have a comment explaining why it needs to use
> inferior_frame to call function.
This frame decorator does not have an inferior_frame API declared, so
in the case of the call to inferior_frame, it calls the super class's
inferior_function API (which in this case, will return self.base).
I'll rename self.base to self._base, in the Frame Decorator. This
example is just deferring the call to the frame decorator that
actually wraps the gdb.Frame.
> Phil> + try:
> Phil> + eliding_frame = next(self.input_iterator)
> Phil> + except StopIteration:
> Phil> + return frame
> Phil> + return ElidingFrameDecorator(eliding_frame, [frame])
>
> What if there are multiple inline frames in a row?
> Wouldn't you want to elide all of them?
> That will make the example trickier though.
Yeah there are several edge cases I did not cover. I did write an
explanatory passage before this example noting that it just covers one
view, and, there are many other cases to deal with. I noted the scope
of a manual example can't encompass these.
Cheers,
Phil
More information about the Gdb-patches
mailing list