hops_control Namespace Reference

::main More...

Namespaces
	__main__
	config
	pass_info

Detailed Description

::main

hops_control - Python-based fringe-fitter control for fourfit4.

Usage in a Python control file (.py)::

    from hops_control import PassInfo, Config

    def configure(p: PassInfo, cfg: Config):
        cfg.ref_freq(215000.0)
        cfg.pc_mode("manual")

        with cfg.IF().station("E"):
            cfg.pc_phases("abcdefgh", [1.0, -2.0, 3.0, -4.0, 5.0, -6.0, 7.0, -8.0])

The ``configure`` function is the single required entry-point.  It receives a
read-only :class:`PassInfo` describing the current fringe pass and a writable
:class:`Config` accumulator.  Every call on *cfg* appends one statement to the
list that fourfit4 will consume. Nested conditional statements are not allowed.

hops_control subprocess entry point.

This is the Python half of the no-embed (subprocess) control-file backend. The
C++ side (MHO_SubprocessPyControlEvaluator + MHO_PythonSubprocessRunner) invokes
it as::

    python -m hops_control <request_file> <response_file>

The C++ side pre-creates both temp files: it writes the request into the first
and reads the JSON response back from the second. Returning the contract through
its own file (rather than stdout) means the exec'd user control script is free
to print() without corrupting what the C++ side parses. It mirrors what the
embedded MHO_PyControlEvaluator does in-process: build a PassInfo + Config, exec
the user's control script to obtain configure(), call configure(pass_info,
config), and return config.to_json(). The condition filtering + command-line
set-string overrides are applied on the C++ side (shared
MHO_ControlEvaluatorSupport), so this entry point returns just the RAW statement
list.

JSON contract (keep in sync with MHO_PythonSubprocessContract.hh):
    request  : { schema_version, pass_info, config, script_path }
    response : { schema_version, ok, statements, error }