undocumented: the move to separate state removed access to the `GhidraScript.state` variable
slippycheeze opened this issue · 3 comments
The splitting out of Python state is cool and all, and make sense.
It had one undocumented side-effect that bit me: previously, state would grab the GhidraState state member from GhidraScript directly and let me access the state that you.
It can be substituted by getState(), which is the Ghidra provided API for it, I suppose. I had to learn that the hard way because, until now, I'd never actually needed to use the API. (Jython provides the same direct access to that variable.)
It may be worth a late-breaking addition to your release notes to save the next person who runs into this the same confusion. (or not, but I figured I'd mention it.)
PS: on the plus side, they upgrade saved a bug report about an interpreter crash that has been fixed along the way, so good work there.
Thank you for reporting this @slippycheeze ! I missed state when reworking the Python 3 builtins for Ghidrathon v3. If you have a moment, please review #75 and let me know if this addresses the specific concerns that you mentioned above.
#75 exposes the GhidraState object using a new state method that is added to the Python 3 builtins scope, e.g.:
> state() == getState()
Truestate was a member variable of GhidraScript, visible to JPython and Ghidrathon, not a function.
the getState() function was always there, too, provided by GhidraScript.
I doubt many, if any, people were using them, but previously there could have been direct access to all the other member variables of GhidraScript like writer as well, same way.
Sorry that wasn't clear; the necessary change to my code was:
tool: PluginTool = state.getTool() # what worked in Ghidrathon 2.2 / JPython
tool: PluginTool = getState().getTool() # ghidrathon 3+Fix released, thanks again @slippycheeze !