Enable int or None as run_condition for Process.run and Runtime.start

[tim-shea]

Issue Number: #768

Objective of pull request: Add logic to create a RunSteps or RunContinuous in Runtime.start when user passes an int or None respectively. This allows users to just call process.run(5) or process.run() and get useful behavior, rather than always importing RunSteps/RunContinuous.

Pull request checklist

Your PR fulfills the following requirements:

• [X] Issue created that explains the change and why it's needed
• [X] Tests are part of the PR (for bug fixes / features)
• [X] Docs reviewed and added / updated if needed (for bug fixes / features)
• [X] PR conforms to Coding Conventions
• [X] PR applys BSD 3-clause or LGPL2.1+ Licenses to all code files
• [X] Lint (flakeheaven lint src/lava tests/) and (bandit -r src/lava/.) pass locally
• [X] Build tests (pytest) passes locally

Pull request type

Please check your PR type:

• [X] Feature

What is the current behavior?

• User must always explicitly create an instance of AbstractRunCondition.

What is the new behavior?

• Runtime.start will implicitly create a RunSteps or RunContinuous if condition is an int or None.

Does this introduce a breaking change?

• [X] No

[PhilippPlank]

I am not sure if I like this change. Calling just <some_proc>.run() does not tell what is going to happen. Also <some_proc>.run(10) or <some_proc>.run(condition=10).

Maybe we can have parameters like: <some_proc>.run(steps=10) or <some_proc>.run(continuous=True) (although False would not really make sense, but I cannot think of a good way to start a continuous run without importing something)

Also blocking and non-blocking mode need to be specified for steps, which is currently part of the condition.

[tim-shea]

I am not sure if I like this change. Calling just <some_proc>.run() does not tell what is going to happen. Also <some_proc>.run(10) or <some_proc>.run(condition=10).

I agree that proc.run(10) is a bit weird and it would be better to add a param called steps. Agree to disagree that proc.run() is ambiguous. It does exactly what it says on the tin: runs.

Maybe we can have parameters like: <some_proc>.run(steps=10) or <some_proc>.run(continuous=True) (although False would not really make sense, but I cannot think of a good way to start a continuous run without importing something)

Also blocking and non-blocking mode need to be specified for steps, which is currently part of the condition.

Adding blocking also as an argument seems like it would resolve these.

• proc.run() would be non-blocking, continuous.
• proc.run(blocking=False) same as previous
• proc.run(blocking=True) would be blocking, continuous. Perhaps should log a warning or info along the lines of "Running a process in blocking, continuous mode. Note that one or more connected processes must request a stop or pause or this will run forever."
• proc.run(steps=N) would be blocking, num-steps
• proc.run(steps=N, blocking=True) same as previous
• proc.run(steps=N, blocking=False) would be non-blocking, num-steps

Someone long ago made the decisions that RunSteps should default to blocking while RunContinuous should default to non-blocking, and while I find that not exactly obvious it has a bit of logic to it and I'm hesitant to change reasonable behavior without a good reason.

[tim-shea]

This isn't necessary. It was just a nice to have.