Add more information to log file?

[kuwisdelu]

Hi Gordon,

Firstly, thanks for adding a GUI executable! While I'd normally prefer the CLI, running the executable via x86 emulation on a Windows ARM VM was the easiest way for me to get TIMSCONVERT working on Apple Silicon. (I ran into difficulty getting Rosetta 2 working through an Ubuntu ARM VM, so I resorted to Windows.)

Anyway, would you consider logging more information?

When conversion via the GUI fails, it isn't obvious why, and the log file only gives the last chunk of frames processed, without any information about the error.

It would also be helpful to include the total number of frames somewhere in the log file so it is easier to get an idea of progress (considering the GUI is unresponsive for very large files).

[gtluu]

Hi Kylie,

Thanks for details on your setup! That's certainly a nice data point to have for my reference. It's good to know the underlying TDF-SDK can be finessed to work on Apple hardware.

Apologies for any confusion. For GUI errors, a separate log file with any errors/warnings is also generated in addition to the existing log file(s) that you typically see from the command line version. This log file will generally be in an arbitrary error directory located in the executable's root directory at [path to]/TIMSCONVERT_2.0.0/errors/[log timestamp]_errors.log.

For now this is a separate log that basically just writes any info that appears the std.err stream, which I believe should capture any errors while running the GUI. Eventually I will probably try to combine the logs to avoid the need to dig around for it when I have some more time, though I haven't found a good way to do that at the moment and I'm still learning my way around Qt.

That being said, I'm open to any suggestions for helpful log information that you would like to be added, so feel free to drop any suggestions!

[kuwisdelu]

Thanks, Gordon. It helps to know where to find the error log for now.

Yes, theoretically I should be able to get Rosetta 2 working in Linux, which should be faster than Windows ARM's x86 emulation. But I haven't been able to get that working on Ubuntu via Parallels yet, so Windows it is!

Two things that would be very helpful for future versions:

1. Log the number of expected spectra to process. For anyone who didn't collect the data and doesn't have access to the Bruker software, it's not obvious how far along the processing is from the log because I don't actually know how many spectra will be converted until it's done.

2. Log if an error came from TIMSCONVERT or the Bruker TDF-SDK. Hopefully this can be done with just a few more strategic try-except blocks around SDK calls. This can help to diagnose whether it is a problem with the actual data file or a TIMSCONVERT issue. The error I recently encountered came from the SDK because the tdf_bin data file itself was incomplete (bad download). I should've caught this by other means, but a "Bruker SDK failed to retrieve spectra #XYZ" message in the log file would have made this much easier. (It took some searching to figure out the error originated from the SDK.)

-Kylie