multiscreen logging

[Sebastian Kügler]

On woensdag 27 juli 2016 13:45:14 CEST Martin Klapetek wrote:
> On Wed, Jul 27, 2016 at 7:35 AM, Sebastian Kügler <sebas at kde.org> wrote:
> 
> On dinsdag 26 juli 2016 19:44:11 CEST Martin Klapetek wrote:
> > On Tue, Jul 26, 2016 at 8:03 AM, Sebastian Kügler <sebas at kde.org> wrote:
> > 
> > What do you think? If you like the idea, I'll polish up my branch and will
> > post it for review, so we can discuss the actual implementation.
> > 
> > I think a possible better way could be to log each component into each own
> > file (in the same dir) with timestamps and function stamps and process
> > stamps and everything and then merge those files using some automation and
> > sort by timestamp. Unless Qt on Linux actually handles concurrent write
> > access just fine and in the correct order (I know it didn't on Windows
> > last
> > time I looked).
> 
> Potentially, yes. Is it a problem? No.
> 
> The log file isn't critical, and *usually* components are able to write in
> order (appending to a file doesn't take long). If the log ends up being
> slightly corrupted, that's bad luck. Instead of implementing complex merging
> tools
> 
> for i in "file1" "file2" "file3"; do cat $i >> output.file; done; cat
> output.file | sort > final.log
> 
> ...not that complex :) Just the sort needs proper params depending on the
> timestamp. 

But that means that tail -f of the combined log becomes more complex.

> or file-locking mechanism, having just these processes write to the same
> file and cross fingers works well enough. It's a debugging tool, file
> integrity is just not that important.
> 
> Dunno, doesn't seem all that useful to have a debugging tool that may
> or may not work, especially if it is ever going to be used by users to post
> in bugreports. What use would be corrupted logs to us? Might as well do
> it properly, especially when the added complexity can be just oneliner
> bash script.

It does work, but it may have a corrupted line or two in the file once in a 
while, which is really no big deal -- not big enough to warrant more complex 
mechanisms. It really is a minor problem, that I haven't even seen yet.
-- 
sebas

http://www.kde.org | http://vizZzion.org