When the tree view tries to render in a sprint scenario, the tree branches are not rendered correctly, eg:
This shows a run using 8 workers. Each invocation takes a random about of time, indicated by the sleep message shown. Notice that the tree branches are now not rendered properly, some of the branches are connected wrong and this is because the sequence of completions are now not guaranteed and the completions will happen out of order. For this reason it appears that using the tree view for a sprint scenario really doesn't make sense.
We have have to re-think the way the --tui flag works. There are some scenarios where certain views are not appropriate. As it stands, the tree-view (flow/linear) is only appropriate for any walk scenario, that mean the walk-cmd and the query-cmd. For sprint commands I intend to create 1 or more views. I can't really restrict each command to a single view(--tui setting), because I always want to allow for multiple views being implemented in the future being appropriate for certain commands.
As it stands:
- walk-cmd, query-cmd: linear-view
- sprint-cmd: no view current available
fore-seeable future views:
- walk-cmd, query-cmd: porthole-view, lanes-view(single lane)
- sprint-cmd: lanes-view(multiple lanes set to --now or --cpu)
##Issues to Foresee:
Validation Timing: If you implement this restriction, you should probably do it at the Cobra PersistentPreRunE or PreRunE level. If a user runs jay sprint --tui linear, they should get a clear error message before the traversal starts, explaining that "linear view requires an ordered traversal; use a walk command or change the view to lanes."
The "Default" Problem: What happens if the user has tui: linear in their jay.yml globally? If they run sprint, it will fail unless you have logic to automatically downgrade or switch to a suitable default for that command.
Intermediate State (Mixed Ordering): Even for walk, if the user eventually adds a post-processing step that happens in parallel, the linear view might break again. Keeping the "View Compatibility" as a first-class property of the ViewKind is a good idea.
Feature Parity: Users might miss certain features of the linear view (like seeing the file paths clearly) when moving to lanes. Ensure the lanes view still provides enough context about what is happening, not just that a worker is busy.
Implementation Suggestion:
In src/prism/prism.go, you could add a method to ViewKind to check for compatibility:
func (vk ViewKind) IsCompatible(concurrency uint) bool {
if concurrency > 1 && vk == LinearView {
return false
}
return true
}This way, the Coordinator or Bootstrap can check this before launching.
When the tree view tries to render in a sprint scenario, the tree branches are not rendered correctly, eg:
This shows a run using 8 workers. Each invocation takes a random about of time, indicated by the sleep message shown. Notice that the tree branches are now not rendered properly, some of the branches are connected wrong and this is because the sequence of completions are now not guaranteed and the completions will happen out of order. For this reason it appears that using the tree view for a sprint scenario really doesn't make sense.
We have have to re-think the way the --tui flag works. There are some scenarios where certain views are not appropriate. As it stands, the tree-view (flow/linear) is only appropriate for any walk scenario, that mean the walk-cmd and the query-cmd. For sprint commands I intend to create 1 or more views. I can't really restrict each command to a single view(--tui setting), because I always want to allow for multiple views being implemented in the future being appropriate for certain commands.
As it stands:
fore-seeable future views:
##Issues to Foresee:
Validation Timing: If you implement this restriction, you should probably do it at the Cobra PersistentPreRunE or PreRunE level. If a user runs jay sprint --tui linear, they should get a clear error message before the traversal starts, explaining that "linear view requires an ordered traversal; use a walk command or change the view to lanes."
The "Default" Problem: What happens if the user has tui: linear in their jay.yml globally? If they run sprint, it will fail unless you have logic to automatically downgrade or switch to a suitable default for that command.
Intermediate State (Mixed Ordering): Even for walk, if the user eventually adds a post-processing step that happens in parallel, the linear view might break again. Keeping the "View Compatibility" as a first-class property of the ViewKind is a good idea.
Feature Parity: Users might miss certain features of the linear view (like seeing the file paths clearly) when moving to lanes. Ensure the lanes view still provides enough context about what is happening, not just that a worker is busy.
Implementation Suggestion:
In src/prism/prism.go, you could add a method to ViewKind to check for compatibility:
This way, the Coordinator or Bootstrap can check this before launching.