we have some progress-bar patching of our logger log function, which leverages tqdm.write to avoid upsetting the progress bar logic:
|
lambda msg: tqdm.write(msg, end=""), |
but either it's broken, or it's scoped improperly as most messages do break the smoothness of the progress bar:
Starting: disruption_py ~ v0.15.0.dev0 # 7efc1eb298ccfac83b86d0e44ce0c0f76b552c7e / user@host
Logging: /tmp/user/disruption-py/2026-08-18/15.19.47-up8tikva/output.log
Resolved tokamak: CMOD
Imported MDSplus.
Database driver fallback: 'ODBC' -> 'ODBC Driver 18 for SQL Server'
Starting workflow: 1 shot / 1 process
0%| | 0/1 [00:00<?, ?it
Database driver fallback: 'ODBC' -> 'ODBC Driver 18 for SQL Server'
#1150805012 | 0.023s : get_ip_parameters
#1150805012 | 0.002s : get_surface_voltage
#1150805012 | 0.012s : get_densities
another issue could be the tqdm expectation vs the (possibly-buffered) log dumping into the terminal coming from different processes during a multiprocessing workflow.
we have some progress-bar patching of our logger log function, which leverages
tqdm.writeto avoid upsetting the progress bar logic:disruption-py/disruption_py/settings/log_settings.py
Line 123 in 166395a
but either it's broken, or it's scoped improperly as most messages do break the smoothness of the progress bar:
another issue could be the
tqdmexpectation vs the (possibly-buffered) log dumping into the terminal coming from different processes during a multiprocessing workflow.