"""D3: does the settings applier actually RUN, and where do the gate bytes'
values come from?

LIVE FACTS this run (pid 260692, slide proven twice):
  configs is served as []  (FUT_SETTINGS is unset -> "off")
  model+0x1fd28 = 60,  +0x1fd2c = 1, +0x1fd2d = 1, +0x1fd2e = 0, +0x1fd2f = 1
  model+0x1fd1c = 0, +0x1fd20 = 0, +0x1fd3a..+0x1fd45 = 1
The disp32 scan says +0x1fd2c and +0x1fd2f have exactly ONE writer each and it is
FUN_18011dc50 (the settings applier), in `sete` form.

HYPOTHESIS: the applier RUNS on every /settings response, even an empty one, and
copies the SETTINGS-RESPONSE STRUCT's own constructor defaults into the model.
The 1s are that struct's defaults; the 0 at +0x1fd2e is that struct's default for
the tradingEnabled field. That makes IS_TRADING_ENABLED=0 an explained, servable
condition rather than an unreachable one.

FALSIFIER: if the settings struct's default for the field feeding +0x1fd2e is 1,
or if the model constructor writes these bytes after all, the hypothesis dies.

CONTROL: model+0x1fd28 reads 60 live and is written by the same applier from
param+0x1c. If the settings struct's constructor default at +0x1c is 60, that is
an independent, non-boolean confirmation that the applier ran -- a boolean 1
could be coincidence, 60 cannot.
"""
import traceback

try:
    for label, a in [
        ("FUN_18011dc50  gate applier (vt+0x988)", 0x18011DC50),
        ("FUN_18011dbf0  size applier (vt+0x998)", 0x18011DBF0),
        ("FUN_180173e00  settings completion callback", 0x180173E00),
        ("FUN_180174580  descriptor builder", 0x180174580),
    ]:
        src = dec(a)
        print("=" * 78)
        print("### %s  @ %#x   len(src)=%d" % (label, a, len(src)))
        print("=" * 78)
        print(src)
        print()
except Exception:
    traceback.print_exc()
