<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 12, 2014 at 9:07 AM, Hermann <span dir="ltr"><<a href="mailto:hvh.net@gmail.com" target="_blank">hvh.net@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">***** High Performance Software Defined Radio Discussion List *****<br>
<br>
</div></div><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 12, 2014 at 3:51 PM, Brian Lloyd <span dir="ltr"><<a href="mailto:brian@lloyd.com" target="_blank">brian@lloyd.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>***** High Performance Software Defined Radio Discussion List *****<br>
<br>
</div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><div>I suggested a very simple hack -- a version number in the database file or, better still, for each logical section of the database file -- but I think Greg's suggestion, while more difficult to do the first time, is a far more universal solution. The database is just a collection of attribute/value tuples. It wouldn't be too hard to have a "rationality checker" for each A/V pair when it is read in during system initialization.  </div>


</div></div></div></blockquote><div><br></div></div>Unfortunately its not only checking the validity of an A/V pair. This is easy and I think this is alreday done. The problem is the combinatorical explosion of A/V paris among each other. While loading the database each possible mode of the software has to be checked, which correspond to a certain subset of A/V pairs. It's like an exhaustive testing of a big state machine, which might take a while, and which is not so easily implemented. Furthermore, this state machine is increasing with each new version.<br>
</div></div></blockquote><div><br></div><div>Yes, you are right if you assume that the probability is that every A/V pair is stateful with respect to every other A/V pair. But for many of the A/V pairs this is not the case, hence my suggestion that one put version numbers in the various sections. Do you think that PA gain calibration is stateful WRT everything else? I don't. It would probably be pretty easy to break that off into its own section of the DB and flag it separately. And for those that obviously are, blow them away and replace them with default values when the version number increments. </div>
<div><br></div><div>So it is possible to address this problem incrementally, with each increment adding more value to the user. Just adding a version number, checking that, and deleting the old DB if the version numbers don't match would help a LOT and be a relatively small amount of code. Version numbers for functional sections of the DB would be incrementally more difficult but would incrementally add function. </div>
<div><br></div></div>-- <br><div dir="ltr">Brian Lloyd            <img src="http://www.catb.org/hacker-emblem/glider.png"><br>Lloyd Aviation<div>706 Flightline Drive<br>Spring Branch, TX 78070<br><a href="mailto:brian@lloyd.com" target="_blank">brian@lloyd.com</a><br>
<span><span id="gc-number-8" class="gc-cs-link" title="Call with Google Voice">+1.916.877.5067</span></span></div></div>
</div></div>