[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: multiscreen logging
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2016-07-27 17:45:14
Message-ID: CAPLgePqXGLbcmF9F68p5vrWORur=JvdhU-MoCFn6OtBS8OnGdg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jul 27, 2016 at 7:35 AM, Sebastian Kügler <sebas@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@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.
> 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.
Cheers
--
Martin Klapetek
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic