<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 27, 2016 at 7:35 AM, Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>On dinsdag 26 juli 2016 19:44:11 CEST Martin Klapetek wrote:<br>
> On Tue, Jul 26, 2016 at 8:03 AM, Sebastian Kügler <<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>> wrote:<br>><br>
> What do you think? If you like the idea, I'll polish up my branch and will<br>
> post it for review, so we can discuss the actual implementation.<br>
><br>
> I think a possible better way could be to log each component into each own<br>
> file (in the same dir) with timestamps and function stamps and process<br>
> stamps and everything and then merge those files using some automation and<br>
> sort by timestamp. Unless Qt on Linux actually handles concurrent write<br>
> access just fine and in the correct order (I know it didn't on Windows last<br>
> time I looked).<br>
<br>
</div></div>Potentially, yes. Is it a problem? No.<br>
<br>
The log file isn't critical, and *usually* components are able to write in<br>
order (appending to a file doesn't take long). If the log ends up being<br>
slightly corrupted, that's bad luck. Instead of implementing complex merging<br>
tools</blockquote><div><br></div><div>for i in "file1" "file2" "file3"; do cat $i >> output.file; done; cat output.file | sort > final.log</div><div><br></div><div>...not that complex :) Just the sort needs proper params depending on the timestamp.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> or file-locking mechanism, having just these processes write to the same<br>
file and cross fingers works well enough. It's a debugging tool, file<br>
integrity is just not that important.<br></blockquote><div><br></div><div>Dunno, doesn't seem all that useful to have a debugging tool that may</div><div>or may not work, especially if it is ever going to be used by users to post</div><div>in bugreports. What use would be corrupted logs to us? Might as well do</div><div>it properly, especially when the added complexity can be just oneliner</div><div>bash script.</div><div><br></div><div>Cheers</div></div>-- <br><div><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">Martin Klapetek</span></div></div></div></div>
</div></div>