Riad S. Wahby
Riad S. Wahby
`ServerInfo` doesn't really have much to do with core mu functionality. `libmu/server.py` has some convenience functions that, e.g., construct help messages and getopt strings, but probably it's better to break...
Yup, exactly.
Sorry, I should have clarified in my previous answer that "breaking out" should only apply to class 2, as you say.
Slightly disorganized thoughts: One minor thing to worry about: implementing this check by having the server talk to S3 means that the server needs to be able to access the...
One more thought: this doesn't need to be the ~~worker's~~coordinator's responsibility. Before launching a job, a separate "checking" stage can catch errors like this. This is probably the best approach...
(edited above: s/worker's/coordinator's/)
@shelbyt the server already keeps track of this at coarser grain---each new state transition is timestamped. Are you trying to do something for which server-side timestamping doesn't work?
What you say makes sense, but it's not at all clear to me that what you describe isn't already provided by the timestamping that the coordinator is doing (modulo two...
@kvasukib 1. Hmm, not quite. The code you're looking at there is run _after_ the coordinator finishes, and it's not writing to the screen, it's writing to a file that...
I mentioned two corner cases where the current timestamping code breaks or is inconvenient. They are: 1. When using a [CommandListState](https://github.com/excamera/mu/blob/master/src/lambdaize/libmu/machine_state.py#L211), there's only one timestamp for the whole state, but...