Hi,
How much memory would be required to always store the output from the relax
controller ?
I modified the controller to only store 10000 lines, as otherwise the
GUI would quite often die:
http://www.nmr-relax.com/api/3.3/gui.controller-pysrc.html#LogCtrl.limit_scrollback
http://www.nmr-relax.com/api/3.3/status-pysrc.html#Status._setup
There is no way to modify the status.controller_max_entries variable
currently, but this may be added as an option in the future. Note
that the GUI element limitations on different operating systems is a
far greater constraint than the total available RAM, especially on MS
Windows. RAM is usually not a consideration for the GUI.
Then if an error is occured, the controller log could be dumped to a file
with a timestamp, and comprresed?
Do you mean automatically? Or we add an option to the popup menu in
the relax controller to save the current text and then ask the user to
create the file manually, if they haven't used the --log or --tee
options? It might be best to give the user the option and let them
decide.
In the auto analysises, a call to dump the controller log could also be
done.
It would be better to do this at the highest level of each UI. Then
the rest of relax code will not need to know about it and would not
change.
Just to make sure, that logs are always preserved.
I know, that they can be of severe size, 50 MB?, ?
This depends on the analysis type, but I have generated log files on
the order of 1-10 Gb. This occurs for the model-free analysis and
N-state model or ensemble analysis quite often. And especially if you
create a custom analysis with a lot of repetition. So a full log file
might be between 1 kb to 10 Gb.
Cheers,
Edward
Best
Troels
2014-11-20 11:44 GMT+01:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
Hi,
Just so you know, due to the fix for bug #22961
(https://gna.org/bugs/?22961), the failure of relaxation data loading
with the message "IndexError: list index out of range", I plan on soon
release a new relax version with this fix. I don't know why relax
users have not reported this problem before, as it is likely to have
been encountered a few times.
Maybe the solution would be to catch all errors, skip the RelaxErrors
so they proceed as normal, and then create a system for automatic bug
submission? This would be a radical and highly disruptive change
though. A different solution would be required for each UI (prompt,
script, and graphical).
The hard part would be to interface with the Gna! infrastructure.
This may make automation impossible. Therefore maybe a set of
instructions for bug submission should be presented to the user. Some
ideas for the text would be:
- "An unidentified error has been encountered."
- Please create a bug report using the link
https://gna.org/bugs/?func=additem&group=relax.
- Copy and paste the entirety of the error message.
- Attach the log file if one was created (or copy and paste the relax
output or rerun relax with the --log or --tee option), compressing if
it is a large file.
- Ideally create truncated input data files for 1 or 2 spins, slightly
randomising the data and changing file names for privacy, and attach
those files.
- Attach a script file, if it exists.
- If the attached data and script files are sufficient to reproduce
the bug, a solution can usually be found within 5 to 10 minutes.
- Run 'relax --info --tee relax_info.log' and attach the
relax_info.log file to the report.
These are just some ideas for the future.
Regards,
Edward
_______________________________________________
relax (http://www.nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Quick release of relax version 3.3.3, and an idea for automatic bug submission when relax crashes.