> Thanks for finding the root cause of this problem. I tried to figure
> it out but didn't quite look hard enough. I also didn't have any
> success with solving the STEP error that is being generated for those
> trying to program their UV-6R.

No problem! I kinda caused the acute user-facing issue with my recent change of the defaults. I knew that was going to cause the rash of issues that is has, but I think it's important to just flush them out and get them fixed, so I've been trying to jump on them.

One thing we can do to try to be more defensive about such things in the future, is use tuples for immutable lists of things. Since they can't be modified they will help defend against such things (and is the trick I used to figure out who was being naughty in this case):

> >>> foo = [1,2,3]
> >>> foo.remove(2)
> >>> bar = (1,2,3)
> >>> bar.remove(2)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'tuple' object has no attribute 'remove'
> >>> bar[0] = 1
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment

By changing uv5r.STEPS to a tuple for a sec, it caused loading of the other driver to fail like the above.

--Dan
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers