NotifyDict register function, should it be able setdefault for keys that are not in the main dict about robotpy-wpilib

[sarosenb]

Also shouldn't hal data be a NotifyDict itself?

[sarosenb]

Also thought on clear, should clear clean out cb as well. I dont think it should mainly due to the fact that the only time we would expect a call to clear to the hal is in reset_hal_data, any other call would break the hal. But I wanted to put out the thought.

[virtuald]

hal_data gets accessed enough that I don't want the extra overhead of notifydict if it's not required most of the time (which it won't be). Anything that we care about notifying I think will be in a subdict. And if it's not, perhaps it should be.

We should probably disable things like clear/delete/etc.

I like the idea of raising an error if register failed -- but it should throw an exception, not return an error code. I'll do that tonight.

[sarosenb]

I though about it throwing, but I wasn't sure that I wanted the whole thing
to die if that mistake is made, but I guess its appropriate. I really like
the idea of hal_data actually being notifydict. It allows people to do
stuff they want with out us changing it because they may have use cases to
test that maybe we have not thought of. To your concern on overhead I
believe that you are acting on your impulse of premature optimization,
remember that this is running on powerful PCs, particularly when doing
simulation the slow down on the use of hal_data will be many times less of
an issue than slow downs other places.

Also the over head is incredibly small, in the case of a none hit you are
slower by a constant time per call to the dic I dont believe it will be a
noticeable hit to operation time. In the case of a hit it does nothing more
than what it should.

Also if you are testing you may want to listen to anything and everything,
we cannot prepredict the use of this module and we should be providing an
interface that people can do whatever they want with without modifying our
expected objects and breaking into our code.

I am pretty confident its the right approach. I want to add this myself
btw. If you disagree let me know why you think that the overhead is worth
the added ugliness of having to add a notifydicts to the table and limiting
the use of the regular structure to the things we expect people to do.

On Fri, Dec 5, 2014 at 2:19 PM, Dustin Spicuzza [email protected]
wrote:

hal_data gets accessed enough that I don't want the extra overhead of
notifydict if it's not required most of the time (which it won't be).
Anything that we care about notifying I think will be in a subdict. And if
it's not, perhaps it should be.

We should probably disable things like clear/delete/etc.

I like the idea of raising an error if register failed -- but it should
throw an exception, not return an error code. I'll do that tonight.

—
Reply to this email directly or view it on GitHub
#50 (comment).

[computer-whisperer]

@sarosenb As far as the overhead goes, gazebo is not the only proposed use for the simulated hal. I think @virtuald still plans to make a simulator environment similar to pyfrc, which is very lightweight. Not all teams have access to computers powerful enough to run gazebo, and they should still have the ability to develop with a reasonably fast simulator environment. The HAL is yet another layer to the system, and should be made to run as fast as possible.

[virtuald]

@sarosenb and I discussed this last night. The conclusion is that the NotifyDict will be used where needed for now, and not at the root until an appropriate use case is discovered. The rationale is that it's easy enough to change it if someone needs it, but there aren't currently any good use cases that we can think of.