DCM notes for 2025-03-03

[glopesdev]

Features

• Improve error tracing in --no-editor mode #2143
• Consider adding Kill Workflow action to Workflow menu #1868

Issues

• Extensions cproj is being formated by the editor and stripped of NL #2055
• Consider saving workflow when program starts #2077
• Saving a group as a workflow doesn't work if the parent workflow hasn't been saved #2035
• Disabled dangling branches lead to runtime differences in subscription behavior #2007
• Ungrouping a nested workflow with a shared externalized property results in corrupted undo stack #2151

[banchan86]

Notes from DCM:

Admin

• Bonsai 2.9 updates:
  • Significant progress has been made over the last few weeks, and several major issues have been resolved.
  • An issue that originally affected the watch feature was traced to a different source and fixed, so the watch feature might actually make it into the next preview.
  • A proper Bonsai 2.9 release in April now seems more achievable and realistic.
  • We took the opportunity to review some remaining backlog issues, gather feedback, and assess whether they could be addressed in time for 2.9.

Issues

• Improve error tracing in --no-editor mode #2143 (more notes in the link)

  • Summary - At a minimum, debugging information available in the editor should also be accessible via the command line when running Bonsai in --no-editor mode.
  • Possible approaches:
    • Unique ID (UID):
      • Currently, Bonsai XML files do not assign UIDs to nodes, making it difficult to trace errors, even if editor output were piped to the command line. Adding UIDs would require modifying the Bonsai workflow XML structure.
      • In addition to error-tracing, UIDs would also solve issues with edge connections, which are currently referenced with just node indexes, and would also make version tracking/merges more straightforward.
      • Implementing UIDs raises broader questions about how to evolve workflow syntax, potentially moving away from implementing an editable syntax similar to Forth.
      • Open question: How should UIDs be generated? (e.g., based on paths?)
    • Reporting XML line numbers:
      • Straightforward to implement right now and which would be compatible with the current Bonsai XML format.
      • Requires saving the workflow on run (see Consider saving workflow when program starts #2077).
      • Could print the nested expression tree up to the error point.
      • Have to consider how to handle IncludeWorkflows.
      • Open question: Would this be truly useful to users?
    • Special editor mode
      • A workaround currently available in the editor is materializing notifications; this could be formalized as a special editor or runtime setting to communicate exceptions to outside processes.
  • Other considerations:
    • By default, the visualizer attempts to run despite exceptions, silently failing instead of piping an error. We might want to disable this behavior—at least as a CLI option—to improve debugging.

• Consider adding Kill Workflow action to Workflow menu #1868

  • Implementing this option is currently difficult due to the editor and workflow execution process being the same. See the linked issue for a detailed breakdown of possible solutions.

• Consider saving workflow when program starts #2077

  • There is consensus that this should be implemented based on previous DCM discussions, but some details still need to be worked out such a quick check to avoid saving workflows when nothing has been changed.
  • A key concern is avoiding interference with expected user behavior, particularly for users who intentionally do not save workflows when calibrating properties for experimental runs or experimenting with new workflows.

Further Discussion

• A broader, recurring discussion that links these issues concerns the purpose of the editor:
  • How are users approaching Bonsai? There seem to be two distinct modes:
    • One as a tool for development/debugging/packaging workflows for running.
    • Two as a tool for running experiments.
  • For some applications it might be ok for these two modes to be intertwined.
  • However, at this point, it may be necessary to separate them and consider redesigning the editor to better accommodate both use cases.