[Scummvm-devel] Log file support

Johannes Schickel lordhoto at scummvm.org
Wed Nov 24 17:39:26 CET 2010


On 11/24/2010 12:34 PM, Thierry Crozat wrote:
> Hi,
>
> On 24 November 2010 10:10, Max Horn <max at quendi.de 
> <mailto:max at quendi.de>> wrote:
>
>     Am 24.11.2010 um 01:41 schrieb Johannes Schickel:
>
>     > 1) Log strategy
>     >
>     > We can basically have two different logging strategies:
>     >
>     > a) only have one log file, which is overwritten on every run.
>     > b) have a fixed maximum of log files and always reuse the oldest
>     one on startup (i.e. log rotation).
>     > c) have an unlimited number of log files.
>
>     I am all for (a) at this point, and will quote myself from a
>     tracker comment:
>
>     Right now I would prefer to go with the "single log file"
>     approach. A single log file is very easy to understand for the
>     user, and there is little risk of the user picking "the wrong
>     one". It is also easiest to implement for us. E.g. no need to
>     rotate log files to prevent the disk from filling up with lots of
>     "-d9" log files.
>
>     Potential drawback is that the user must remember to copy it right
>     away, before re-starting ScummVM, else it is lost. This is mostly
>     a problem for "rare" hard-to-reproduce issues. If the user can
>     easily reproduce it, then they are just fine either way. Moreover,
>     if we crash into the debugger console, we could display a text
>     there like "If you want to file a bug report on this, you can find
>     a log file with relevant info in location XYZ. Please copy it NOW,
>     before restarting ScummVM, otherwise it will get overwritten."
>     Well, something like that, at least.
>
> It seems given here that one log file corresponds to one run of 
> ScummVM, yet I have seen no discussion of this. Many applications (on 
> Linux at least, I am not very familiar with other systems) use a 
> single log file and append logs to them with a timestamp when 
> restarting the application. This files can get very big but we could 
> improve a bit the system by overwritting the file if for example the 
> creation date is not today (i.e. all the runs for a day are stored in 
> the log file and the files get overwritten the next day). For the user 
> this would still be simple (only one log file) and remove some of the 
> problem of overwritting the log file when restarting ScummVM. One 
> drawback is that this file may still get big (especially when making 
> several run with -d9, but maybe if the user knows how to start an 
> application with -d9 he would not mind to much having to manually 
> delete the old log file if he wants to have a clean log for a new run).


Another drawback is that if the user submits a log it might not be clear 
which of the embedded "sub" logs is actually the one from the bug 
report, especially if he does another run after he encountered the bug 
first.


>
> I don't know if this is a good idea, but just wanted to say that there 
> may be more options than just the three proposed by Johannes.

As you might have noticed that first sentence shouldn't be there either, 
since it does only talk about "two" different strategies aye. But yeah 
there are other alternatives there and thanks for bringing this one up.

// Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20101124/c5d9d907/attachment.html>


More information about the Scummvm-devel mailing list