DM-39105: Write TMA state machine and event generator

[mfisherlevine]

No description provided.

[r-owen]

This is as far as I got today. I'll do more tomorrow if I have time.

[r-owen]

This mix of continue and loops within loops looks a bit complicated to me. Consider something like the following:

previousState = None
for rowNum, state in enumerate(states):
    if state in skipStates:
        previousState = None
        continue
    if state != previousState:
        eventStart = rowNum
        previousState = state
    parsedStates.append((...))
if previousState is not None:
    self.log.warning("Reached the end...")

Though I think your code appends the ending skipState to parsedStates. If you really want to do that, tweak the "if state in skipStates" a bit, e.g.:

if state in skipStates:
    if previousState is not None:
        parsedStates.append(...)
        previousState = None
    continue

[mfisherlevine]

Sorry, I've tinkered with this for a little while now and I can't seem to make this work quite the same way - something to do with needing to move through the event (which can have many states which are all the same, and should only end once the state changes). I agree the code I've written is pretty ugly, but all the alternative ways I've tried have come out just as ugly so far, so I think I might just have to leave it as-is for now 😔

[isullivan]

I made it through everything but the unit tests, which I skimmed and didn't feel I had constructive comments about. I did not comment on code that I found Russell had already commented on.

[isullivan]

Perhaps raise a RuntimeError inside an if statement instead of bare asserts.

[mfisherlevine]

This gets a little philosophical, but in my head at least, assert statements are used for things which should logically/definitionally never be possible, and are used to indicate that in code (i.e. sanity/consistency checks which should never fail, ever, and if they do, some function isn't doing what you thought it did). ifs and raises in places like that, - again, at least in my mind - are for things which one needs to check, defend against, and raise on when found, so this was why I chose naked asserts here rather than check & raise. (Also, I think naked asserts, for this reason, can be dropped at runtime, whereas if/raises cannot).

[psferguson]

clipDataToEvent does not currently appear in the __all__ of efdUtils.py
https://github.com/lsst-sitcom/summit_utils/blob/b9b564d8d4fb94c45e3362bc17dcb7ccc08d9073/python/lsst/summit/utils/efdUtils.py#L37