6:38 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=5041
Summary: avoid use of stdout/cout, route through our own
logging code
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Generic
OS/Version: Other
Status: ASSIGNED
Severity: normal
Priority: P2
Component: * Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Usage of stdout and cout should be avoided. Currently the SyncEvolutionCmdline
class is still told to write into cout by syncevolution.cpp.
When compiling SyncEvolution .cpp code, any reference to stdout or cout should
trigger a compiler error (redefine the symbols?!). Some with printf, puts, etc.
Instead of cout, a custom stream which passes the data into our logging system
with a suitable tag that reproduces the output verbatim on the console and logs
it in the normal log should be used.
Running commands must redirect stdout of the processes and ideally keep
processing that output while the command runs (rules out simple system()
calls).
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:48 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |5042
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:54 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |5043
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:21 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 2010-02-18 06:21:54 PST ---
Another benefit of this would be that the new SyncEvo::LogDirTest doesn't get
cluttered by session output. We could even test that the right output is
produced,
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:52 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
yongsheng zhu <yongsheng.zhu(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yongsheng.zhu(a)intel.com
--- Comment #2 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-10 01:52:37 PST
---
If rewriting synevolution command line with dbus server, is it still a problem?
Info from dbus server printed to console is ok for me, do we really need
redirect it to logging files and std output?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:06 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #3 from pohly <patrick.ohly(a)intel.com> 2010-03-10 06:06:12 PST ---
(In reply to comment #2)
If rewriting synevolution command line with dbus server, is it still
a problem?
Info from dbus server printed to console is ok for me, do we really need
redirect it to logging files and std output?
Reimplementing the command line via D-Bus calls is going to be more work than
fixing the output handling. Therefore I think this issue still applies.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:30 p.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #4 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-16 19:30:11 PST
---
(In reply to comment #0)
Usage of stdout and cout should be avoided. Currently the
SyncEvolutionCmdline
class is still told to write into cout by syncevolution.cpp.
When compiling SyncEvolution .cpp code, any reference to stdout or cout should
trigger a compiler error (redefine the symbols?!). Some with printf, puts, etc.
you
mean all files in SyncEvolution core or just syncevolution.cpp? If yes,
Instead of cout, a custom stream which passes the data into our
logging system
with a suitable tag that reproduces the output verbatim on the console and logs
it in the normal log should be used.
it's good for command line. what's the
'tag' for? to determine whether to
reproduce the output on the console or log it in the normal log, or both?
Since dbus server might also call Cmdline class, I think the custom stream for
it might be changed: log it to normal system and send them to dbus client.
Running commands must redirect stdout of the processes and ideally
keep
processing that output while the command runs (rules out simple system()
calls).
I don't understand it. Redirect stdout of processes which are started
by
syncevolution?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
10:20 p.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #5 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-16 22:20:49 PST
---
Instead of cout, a custom stream which passes the data into our
logging system
with a suitable tag that reproduces the output verbatim on the console and logs
it in the normal log should be used.
what's the 'normal log' here? the
current used logger in the top of loggers
stack? what if the normal log is to send log to stdout for we know the default
Logger outputs the log to stdout?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12:09 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #6 from pohly <patrick.ohly(a)intel.com> 2010-03-17 00:09:12 PST ---
(In reply to comment #4)
(In reply to comment #0)
> Usage of stdout and cout should be avoided. Currently the SyncEvolutionCmdline
> class is still told to write into cout by syncevolution.cpp.
>
> When compiling SyncEvolution .cpp code, any reference to stdout or cout should
> trigger a compiler error (redefine the symbols?!). Some with printf, puts, etc.
you mean all files in SyncEvolution core or just syncevolution.cpp? If yes,
Did you mean to write more here?
I mean primarily the SyncEvolution core. That's were most of the output is
generated.
> Instead of cout, a custom stream which passes the data into our
logging system
> with a suitable tag that reproduces the output verbatim on the console and logs
> it in the normal log should be used.
it's good for command line. what's the 'tag' for?
I think I meant something like INFO/ERROR. Instead of inserting those into a
character data stream, the data sent to the client for formatting should be
similar to what our logging code gets. Then for "normal" output we need
something that says "don't add any prefix".
to determine whether to
reproduce the output on the console or log it in the normal log, or both?
Logging into the file would be done inside the engine, not at the recipient.
> Running commands must redirect stdout of the processes and
ideally keep
> processing that output while the command runs (rules out simple system()
> calls).
I don't understand it. Redirect stdout of processes which are started by
syncevolution?
Yes. This is required for example for "synccompare". We already do that for
stderr.
(In reply to comment #5)
> Instead of cout, a custom stream which passes the data into our
logging system
> with a suitable tag that reproduces the output verbatim on the console and logs
> it in the normal log should be used.
what's the 'normal log' here? the current used logger in the top of loggers
stack? what if the normal log is to send log to stdout for we know the default
Logger outputs the log to stdout?
The normal log is the syncevolution-log.html file. How to find that in the
Loggers is a different question that I can't answer without looking at the
code.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
1:27 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #7 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-18 01:27:05 PST
---
I think I meant something like INFO/ERROR. Instead of inserting those
into a
character data stream, the data sent to the client for formatting should be
similar to what our logging code gets. Then for "normal" output we need
something that says "don't add any prefix".
Since now Cmdline uses
'operator <<' to output text, to decrease changes, I'd
like to define a new class passed to Cmdline:
class CmdlineOStream : public ostream {
void setLevel(Level level);
};
//Cmdline constructor
Cmdline(int argc, const char * const *argv, CmdlineOStream &out)
If a level is set, then the output text through this ostream is unless the
level is changed. This could avoid many changes in Cmdline class. However, this
method gives the user to decide where to put output(output on the console, log
into the top logger of loggers stack).
Instead of cout, a custom stream which passes the data into our
logging system
with a suitable tag that reproduces the output verbatim on the console and logs
it in the normal log should be used.
Command line won't use the log file 'syncevolution-log.html' only when a
session is started. you want to change this?
Logging into the file would be done inside the engine, not at the
recipient.
it seems inconsistent. I understand the custom stream is passed by
invokers and
in charge of reproduces output on the console and log it in the log in the
first paragraph.
Yes. This is required for example for "synccompare". We
already do that for
stderr.
so redirecting stdout to '/dev/null' like stderr processing for
"synccompare"
is enough?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:19 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #8 from pohly <patrick.ohly(a)intel.com> 2010-03-18 02:19:07 PST ---
(In reply to comment #7)
> I think I meant something like INFO/ERROR. Instead of inserting
those into a
> character data stream, the data sent to the client for formatting should be
> similar to what our logging code gets. Then for "normal" output we need
> something that says "don't add any prefix".
Since now Cmdline uses 'operator <<' to output text, to decrease changes,
I'd
like to define a new class passed to Cmdline:
class CmdlineOStream : public ostream {
void setLevel(Level level);
};
//Cmdline constructor
Cmdline(int argc, const char * const *argv, CmdlineOStream &out)
If a level is set, then the output text through this ostream is unless the
"is" what? Redirected?
Who calls setLevel() and why? I don't see a need for it.
When using Cmdline without D-Bus, pass std::cout. When using it inside
syncevo-dbus-server, implement a class derived from ostream which redirects
output via D-Bus. There must be virtual methods inside ostream which can be
used for that. The << operator itself cannot (and shouldn't) be used for that,
because it is not virtual and has different implementations, depending on the
right side of it.
> Instead of cout, a custom stream which passes the data into our
logging system
> with a suitable tag that reproduces the output verbatim on the console and logs
> it in the normal log should be used.
Command line won't use the log file 'syncevolution-log.html' only when a
session is started. you want to change this?
I was just saying that if such a file is written, it will be written by the
syncevo-dbus-server, not the client.
> Logging into the file would be done inside the engine, not at
the recipient.
it seems inconsistent. I understand the custom stream is passed by invokers and
in charge of reproduces output on the console and log it in the log in the
first paragraph.
Writing into the log file is done by LogDir, which implements LoggerBase. In
addition to writing into the file, it also invokes m_parentLogger. That logger
could either write to stdout or emit the D-Bus signals.
> Yes. This is required for example for "synccompare".
We already do that for
> stderr.
so redirecting stdout to '/dev/null' like stderr processing for
"synccompare"
is enough?
No. We want to *have* that output, not *discard* it ;-) What I referred to is
LogRedirect. Currently we only capture stderr and filter it. As soon as none of
our core code writes to file descriptor 1 anymore, we can also capture that
descriptor and pass it through our logging infrastructure, exactly like our own
"stdout" output. That way it will be recorded in
"syncevolution-log.html", if
it exists, (new and useful feature) in addition to being sent via D-Bus to the
syncevolution D-Bus client.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8:16 p.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #9 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-21 20:16:11 PST
---
I think I meant something like INFO/ERROR. Instead of inserting those
into a
character data stream, the data sent to the client for formatting should be
similar to what our logging code gets. Then for "normal" output we need
something that says "don't add any prefix".
I define a tag
'SHOW' like 'INFO/ERROR', which means only show output without
any extra information(like tag and prefix) when printing.
No. We want to *have* that output, not *discard* it ;-) What I
referred to is
LogRedirect. Currently we only capture stderr and filter it. As soon as none of
our core code writes to file descriptor 1 anymore, we can also capture that
descriptor and pass it through our logging infrastructure, exactly like our own
"stdout" output. That way it will be recorded in
"syncevolution-log.html", if
it exists, (new and useful feature) in addition to being sent via D-Bus to the
syncevolution D-Bus client.
got it. for simple 'system' calls, it seems to
me it's hard to redirect their
and route them into our logging system. so like you said, we discard them,
right?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12:25 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2010-03-22 00:25:35 PST ---
(In reply to comment #9)
> No. We want to *have* that output, not *discard* it ;-) What I
referred to is
> LogRedirect. Currently we only capture stderr and filter it. As soon as none of
> our core code writes to file descriptor 1 anymore, we can also capture that
> descriptor and pass it through our logging infrastructure, exactly like our own
> "stdout" output. That way it will be recorded in
"syncevolution-log.html", if
> it exists, (new and useful feature) in addition to being sent via D-Bus to the
> syncevolution D-Bus client.
got it. for simple 'system' calls, it seems to me it's hard to redirect
their
and route them into our logging system. so like you said, we discard them,
right?
Once file descriptor 1 of the syncevo-dbus-server is redirected, all other
processes spawned from it (including those with system()) will use that pipe.
So we don't have to do anything special and we don't need to discard that
output.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
1:14 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #13 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-26 01:14:32
PST ---
It seems to me that the D-Bus server should have better means of
finding the
currently active session, like, um, DBusServer::m_activeSession? ;-)
I see, but i
think there is one premise: there is at most one active session at
a time and when it exists, all outputs are belonging to the session instead of
a DBusServer, right? If you think it is proper, I'll change it.
patrick: yzhu17: I started hacking on the "don't use
std::cout" part in
Cmdline.cpp and SyncContext.cpp. Let me know if you interested in that patch, if >
not, I'll just throw it away.
please do it.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
1:43 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 2010-03-26 01:43:09 PST ---
(In reply to comment #13)
> It seems to me that the D-Bus server should have better means of
finding the
> currently active session, like, um, DBusServer::m_activeSession? ;-)
I see, but i think there is one premise: there is at most one active session at
a time and when it exists, all outputs are belonging to the session instead of
a DBusServer, right? If you think it is proper, I'll change it.
Yes, please change. The assumptions of "all output belongs to current session"
and "there is only one such session" already exist in the form of one global
logger instance. We can rely on it for the time being.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:20 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #15 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-03-26 02:20:53
PST ---
(In reply to comment #14)
(In reply to comment #13)
> > It seems to me that the D-Bus server should have better means of finding the
> > currently active session, like, um, DBusServer::m_activeSession? ;-)
> I see, but i think there is one premise: there is at most one active session at
> a time and when it exists, all outputs are belonging to the session instead of
> a DBusServer, right? If you think it is proper, I'll change it.
Yes, please change. The assumptions of "all output belongs to current session"
and "there is only one such session" already exist in the form of one global
logger instance. We can rely on it for the time being.
thanks, done.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:34 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2010-03-26 02:34:03 PST ---
(In reply to comment #13)
> patrick: yzhu17: I started hacking on the "don't use
std::cout" part in
> Cmdline.cpp and SyncContext.cpp. Let me know if you interested in that patch, if
> not, I'll just throw it away.
please do it.
Okay, code in "pohly" branch. The LogDirTest now passes without extra output,
which should fix the issue mentioned in comment #1. This needs to be tested in
combination with the other changes before merging.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
10:13 a.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INTEGRATED
--- Comment #21 from pohly <patrick.ohly(a)intel.com> 2010-04-15 10:13:01 PST ---
In MeeGo builds 0.9.99.19 or 0.9.99.20.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:15 p.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
--- Comment #22 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-04-18 19:15:04
PST ---
Please see http://bugzilla.moblin.org/show_bug.cgi?id=5042#c8 to see how to
verify this bug.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:05 p.m.
New subject: [Bug 5041] avoid use of stdout/cout, route through our own logging code
http://bugzilla.moblin.org/show_bug.cgi?id=5041
ZhangJingke <jingke.zhang(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
CC| |jingke.zhang(a)intel.com
--- Comment #23 from ZhangJingke <jingke.zhang(a)intel.com> 2010-04-18 20:02:37 PST
---
(In reply to comment #22)
Please see http://bugzilla.moblin.org/show_bug.cgi?id=5042#c8 to see
how to
verify this bug.
With syncevolution-0.9.99.19, I retest syncevolution as Yongsheng's steps.
Sync with Funambol can PASS and the output from both dbus console and command
line are exactly same. Verify this bug now. Thanks!
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4245
days inactive
4503
days old
syncevolution-issues@syncevolution.org
19 comments
1 participants
participants (1)
-
bugzilla＠moblin.org