<div dir="ltr">On Wed, Mar 13, 2013 at 11:52 AM, Dan Smith <span dir="ltr"><<a href="mailto:dsmith@danplanet.com" target="_blank">dsmith@danplanet.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Wow, this is a lot of work, thanks for doing it!<br>
<div class="im"><br>
> You can select multiple plans because, for example, you might want<br>
> both an IARU plan and a country plan.<br>
<br>
</div>So, from reading part of the code, I got the impression that perhaps<br>
the plans are/should be hierarchical. Meaning, that the NA plan is a<br>
subset of IARU 2. Is that the case?</blockquote><div><br></div><div style>Yes, however a North American Marine band plan and a North American Amateur band plan would both be under an ITU region 2 band plan, and you might want to use both.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I ask because I'm wondering if it<br>
makes more sense to let folks choose IARU 2 or NA (which would inherit<br>
from IARU, and perhaps override some bits) instead of this<br>
mix-and-match behavior. I don't think it would make much sense to have<br>
NA and IARU 1 enabled at the same time, for example, but maybe I'm<br>
wrong. Of course, that has me thinking that we should be utilizing<br>
inheritance...<br></blockquote><div><br></div><div style>You're right. I'll try it with objects and see how it looks. I expect that will make it easier to calculate and claim the repeater input blocks too (with opposite offsets).</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> The format in bandplan_au.py is the format I prefer. The format in<br>
> bandplan_na.py is carried over from chirp_common.py and should be<br>
> replaced by the new format once we agree on how it should look.<br>
<br>
</div>It's very close to what I pulled out of thin air earlier, and overall I<br>
think I'm fine with it. I do wonder if we should be using objects<br>
instead of just primitives, but I'm not sure.<br>
<div class="im"><br>
> While testing this I noticed that there are multiple instances of the<br>
> config class, with different and overlapping lifetimes. This means<br>
> that sometimes configuration changes are applied and sometimes they<br>
> are not. That is a separate issue.<br>
<br>
</div>Hmm? Config is a singleton, and the various proxy objects should just be<br>
views into it. I've not seen any such issues, but if you find them, we<br>
should definitely get them resolved.<br></blockquote><div><br></div><div style>I've filed bug #683</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> + "bands": {<br>
> + (28.000e6, 29.700e6): {<br>
<br>
I don't like the specification of these as floats. Can we use ints,<br>
perhaps with easy shortcut helpers such as:<br>
<br>
(k(28000), k(28700))<br>
<br>
and<br>
<br>
(m(146), m(148))<br></blockquote><div><br></div><div style>Sounds good to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> +def _walk_bandplan(freq, bandplan, defaults):<br>
> + # Override defaults with values from this level.<br>
> + for name in defaults:<br>
> + defaults[name] = bandplan.get(name, defaults[name])<br>
> +<br>
> + # Go more specific if the frequency fits within an available<br>
> sublevel.<br>
> + for key, vals in bandplan.items():<br>
> + if key in defaults:<br>
> + pass<br>
> + elif isinstance(key, tuple):<br>
> + if key[0] > key[1]:<br>
> + raise Exception("Invalid range %s - %s" % key)<br>
> + if int(freq) >= key[0] and int(freq) < key[1]:<br>
> + _walk_bandplan(freq, vals, defaults)<br>
> + break<br>
> + else:<br>
> + raise Exception("Invalid key %s" % key)<br>
<br>
This just screams at me for the use of an object structure instead of<br>
primitives. Is there a reason you decided against it? (other than me<br>
firing off a half-baked concept earlier, of course :P)<br></blockquote><div><br></div><div style>I'll try what you suggest.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> + <menu action="bandplan" name="bandplan"><br>
> + <menuitem action="north_america"/><br>
> + <menuitem action="australia"/><br>
> + </menu><br>
<br>
This is fine, of course, and we don't have many here right now, but we<br>
can automate the generation of the submenu so that adding a new<br>
bandplan is a little less involved.<br>
<br>
> + # Migrate old "automatic repeater offset" setting to<br>
<br>
Thanks for this!<br>
<br>
Otherwise, I think it looks fine. Again, thanks a lot for taking on<br>
this non-trivial thing :)<br></blockquote><div><br></div><div style>No worries.</div><div><br></div></div>-- <br><div><span style="color:rgb(102,102,102)">Sean Burford <<a href="mailto:sburford@google.com" target="_blank">sburford@google.com</a>></span></div>
</div></div>