New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IntrospectionServer and PicklingError: explicitly exclude variables from being pickled #18
Comments
Ah interesting. Yeah, there's no current way to do this. I like your idea, but let me think about which class should be responsible for checking this. I think the first thing to do, is catch the error, and display a non-breaking error message. I can patch that when I get a minute (the IntrospectionServer is really simple), or you're welcome to submit a pull request. I like the idea of being able to exclude UserData keys from being pickled, also, since type objects are first-class citizens in python, you could also exclude objects based on their datatype. Even further, you could set a maximum data size for the introspection status messages. The pickling happens in the IntrospectionServer, but it pickles the whole UserData dict, itself, so pulling apart individual keys would require either copying the structure without the keys, iterating through the keys and pickling them individually, or overriding UserData's What I don't like is specifying state names and excluded UserData keys at the level of the IntrospectionServer. I think if any userdata keys should be excluded from pickling, they should be excluded at the Container (StateMachine, Concurrence, etc.) level (since that's where the UserData actually lives). Otherwise, you end up having to maintain facets of your plan structure in multiple places. So then the change that I think would make the most sense would be to add a new optional argument to the Container classes (StateMachine, Concurrence, etc), maybe "private_keys" which could then be passed to each container's UserData structure. Then to modify UserData's Something else that could be done, is to overload UserData's If you're interested in doing this, it'd be a great addition! As an aside, the IntrospectionServer is pretty inefficient, and I think it could be improved a lot, in general (see #5). |
Either of the pickling method you suggested would be fine. I like the
The counterargument is, that the State does not need to know about the introspection of the introspection server. But on the other hand, you're right. You have to maintain the states in multiple places.
How can we know if something is pickle-able? I like your idea of excluding certain types and limit the size! This feature, I think, should be part of the For this example, I'll just stick to my previous suggestion, just because... sis = smach_ros.IntrospectionServer(
'sis', sm, '/SM_ROOT',
exclude_userdata={
BlaState: ["variable1", "variable2"],
FooState: ["variableX"]
},
exclude_types=[ReallyBigClass, int],
max_size=1000
) What do you think? |
You're not, by any chance, at the RosCon 2013 right now? |
Haha yes, I am. -j On Sat, May 11, 2013 at 5:37 AM, Stefan Otte notifications@github.comwrote:
Jonathan Bohren |
so how should we proceed with this? |
I just got back to the states. Have you tried making the modification we discussed above yet? |
I have some variables in a state which should not be pickled by the
IntrospectionServer
. This is of interest for me, first of all, because I get anPicklingError
right now (it seems thatSwigPyObjects
can't be pickled), but more generally, because they are too big and I don't want them to be serialized.I guess I'm looking for something like this:
Is there a way to do this? If not, could we implement something like this? I'd be happy to help!
The text was updated successfully, but these errors were encountered: