Re: [SyncEvolution] gdbus-cxx and methods in base classes
On Wed, 2009-10-14 at 04:29 +0100, Zhu, Yongsheng wrote:
Yongsheng, can you
review this so? It's ready to replace the current code in the dbus-api
branch.
New solution uses boost bind and function to solve the issue. It should be
workable.
But I have a concern about private inheritance and boost bind.
When boost does binding for a instance and a function member of its base
classes,
if the class of the instance privately or protectedly
inherits from its base class, boost binding could not access that function
and
raises errors.
The base class is only inaccessible in DBusObjectHelper. The class
registering the method in the base class has access to it. So this
example fails, as you said:
class Test2
{
public:
void test2() {}
};
class DBusTest : public Test, private Test2
{
DBusTest(DBusConnection *conn) :
{
m_object.add(this, Test2::test2, Private);
But this code here works:
m_object.add(static_castTest2 *(this), Test2::test2, Private);
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] gdbus-cxx and methods in base classes
Yes, make sense. Thanks.
Cheers,
Yongsheng
-Original Message-
From: Ohly, Patrick
Sent: Wednesday, October 14, 2009 3:09 PM
To: Zhu, Yongsheng
Cc: SyncEvolution
Subject: RE: [SyncEvolution] gdbus-cxx and methods in base classes
On Wed, 2009-10-14 at 04:29 +0100, Zhu, Yongsheng wrote:
Yongsheng, can you
review this so? It's ready to replace the current code in the dbus-api
branch.
New solution uses boost bind and function to solve the issue. It should be
workable.
But I have a concern about private inheritance and boost bind.
When boost does binding for a instance and a function member of its base
classes,
if the class of the instance privately or protectedly
inherits from its base class, boost binding could not access that function
and
raises errors.
The base class is only inaccessible in DBusObjectHelper. The class
registering the method in the base class has access to it. So this
example fails, as you said:
class Test2
{
public:
void test2() {}
};
class DBusTest : public Test, private Test2
{
DBusTest(DBusConnection *conn) :
{
m_object.add(this, Test2::test2, Private);
But this code here works:
m_object.add(static_castTest2 *(this), Test2::test2, Private);
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] writing unit tests for our new D-Bus API
On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote: dbus-monitor buffers its output and doesn't flush it when exiting, which means that output is lost. Stupid dbus-monitor. No solution :-/ dbus-monitor has broken SIGINT handling and no handling of SIGTERM. Because of its brokeness, distros patch this out of their dbus-monitor binaries. Here's a patch which fixes dbus-monitor. I'm not sure yet how useful catching a D-Bus log with dbus-monitor will be - we'll see... commit f6719df9e3a545acf8600970190d3bd89cfd390a Author: Patrick Ohly patrick.o...@gmx.de Date: Wed Oct 14 14:20:00 2009 +0200 dbus-monitor: fix for CTRL-C/SIGINT and SIGTERM CTRL-C/SIGINT had no effect because dbus_connection_read_write_dispatch() continues with poll() after an interrupted system call. This caused Debian and Ubuntu to remove the signal handling code since 1.1.1-1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414139 This patch solves the problem using brute force: a timeout of 500ms ensures that dbus_connection_read_write_dispatch() is left often enough to react to signals in a more or less timely manner. Nicer solutions are of course possible (custom main loop), but also more intrusive. In addition, this patch also catches SIGTERM. This is the default signal used by kill and Python's subprocess.terminate() and thus worth handling. diff --git a/tools/dbus-monitor.c b/tools/dbus-monitor.c index 873108b..03600b0 100644 --- a/tools/dbus-monitor.c +++ b/tools/dbus-monitor.c @@ -339,9 +339,15 @@ main (int argc, char *argv[]) exit (1); } - /* we handle SIGINT so exit() is reached and flushes stdout */ + /* we handle SIGINT and SIGTERM so exit() is reached and flushes stdout */ signal (SIGINT, sigint_handler); - while (dbus_connection_read_write_dispatch(connection, -1) + signal (SIGTERM, sigint_handler); + /* + * The signal alone won't get us out of dbus_connection_read_write_dispatch(), + * it seems to simply call poll() again. Check for termination every + * 500ms. + */ + while (dbus_connection_read_write_dispatch(connection, 500) !sigint_received) ; exit (0); -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] writing unit tests for our new D-Bus API
On Tue, 2009-10-13 at 15:38 +0100, Patrick Ohly wrote: What do you think about this? As there were no cries of outrage, I went ahead and improved the test script. While extending the tests I already found different issues in the implementation: * Server.GetConfigs() missing * Session.Status and Session.Progress signal names instead of Session.StatusChanged and Session.ProgressChanged * Session status changed from queueing to running instead of going to idle first Currently the script is able to run a real sync via the D-Bus API, which can also be used to add more checks that progress reporting etc. works. Configuration of the script is still hard-coded. See the updated script and log message for details. I'll let it sit for a few days, so if someone else wants to work on it, feel free. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] [os-libsynthesis] Base64 data line folding in vCard2.1
On Wed, 2009-10-14 at 11:49 +0100, Lukas Zeller wrote: [look ahead to detect B64 properties which continue on the next line] I'll have a look how complicated this would be to implement - it will not be trivial because the layering in the current implementation first separates properties and then parses them, and the lookahead would require reversing some of that. It was surprisingly easy - I added a patch 8893914593 (vcard/vcal B64 properties: added workaround to recognize improperly folded B64 properties) on synthesis indefero unilib branch. Thanks Lukas! Congwu, can you backport this to the master branch in libsynthesis on moblin.org so that we can include it in 0.9.1? I would have done it myself but ran out of time today. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[Syncevolution-issues] [Bug 6664] vCalendar 1.0: priorities of tasks not matched with other applications (Mobical)
http://bugzilla.moblin.org/show_bug.cgi?id=6664
--- Comment #5 from yongsheng zhu yongsheng@intel.com 2009-10-14
01:02:53 ---
(In reply to comment #4)
(In reply to comment #3)
We should use the iCalendar 2.0 range internally in the Synthesis field
list
and map to the smaller 1-3 range when talking to peers in vCalendar 1.0.
so I'll map iCalendar 2.0 range to vCalendar1.0, not only for Mobical.
Correct.
Mobical is the only server we exchange tasks with using vCalendar 1.0, isn't
it?
There should be 4 places we have to check and do the conversion:
client backend read, client backend write, server incoming, outgoing to server
.
Server side:
if an incoming task and its type is vCalendar1.0,
do priority conversion after incoming in 'incomingscript'
if an outgoing task and its type is vCalendar1.0,
do priority conversion before outgoing in 'outgoingscript'
These 2 scripts are global and can be applied for all servers when
sending/receving tasks.
client backend
if reading a task from client backend,
do priority conversion after read in 'afterreadscript'.
if wanting to write a task to client backend,
do priority conversion before writing in 'beforewritescript'
Since these should be applied for all vCalendar1.0 related backends, but
currently there is no mechanism to support this in our code though we have
backend specified scripts(bug5633 asks) for them.
So I suggest adding a mechanism to solve this issue.
One global script should be defined for each kind of data type. And for each
backend source, we check its mimetype and firstly invoke its own specified
script for that source and then invoke our global scripts. Below is the code
from SyncSource:
beforewritescript![CDATA[\n;
if(!info.m_incomingScript.empty()) {
xmlstream
info.m_incomingScript \n;
}
/// check its mimetype and add corresponding global scripts
xmlstream
itemdata = MAKETEXTWITHPROFILE( info.m_profile
, \EVOLUTION\);\n
]]/beforewritescript\n
In bug5633, we add two fields 'm_incomingScript' and 'm_outgoingScript' and I
think their names are not suitable. They should use 'm_afterreadscript' and
'm_beforewritescript' for client backends.
Another possible issue is:
if we read a task in iCalendar2.0 format from client backend with a priority
and then send it in vCalendar1.0, then when refreshing from server, we might a
different priority value other than our sent and they should belong to one
category(high, normal, low). In some servers, if it has more than 3 categories,
like memotoo, which has 5 categories, very high, high, normal, low, very low,
this conversion could make some problems on its web page view.
--
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.
___
Syncevolution-issues mailing list
Syncevolution-issues@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6664] vCalendar 1.0: priorities of tasks not matched with other applications (Mobical)
http://bugzilla.moblin.org/show_bug.cgi?id=6664
--- Comment #6 from pohly patrick.o...@intel.com 2009-10-14 01:21:47 ---
(In reply to comment #5)
(In reply to comment #4)
So I suggest adding a mechanism to solve this issue.
One global script should be defined for each kind of data type. And for each
backend source, we check its mimetype and firstly invoke its own specified
script for that source and then invoke our global scripts.
Doing the right thing by default sounds, eh, right. But I think we should give
a backend the chance to override that. For example, it might use its own custom
mapping for priorities despite using vCalendar 1.0.
Below is the code
from SyncSource:
beforewritescript![CDATA[\n;
if(!info.m_incomingScript.empty()) {
xmlstream
info.m_incomingScript \n;
}
/// check its mimetype and add corresponding global scripts
xmlstream
itemdata = MAKETEXTWITHPROFILE( info.m_profile
, \EVOLUTION\);\n
]]/beforewritescript\n
In bug5633, we add two fields 'm_incomingScript' and 'm_outgoingScript' and I
think their names are not suitable. They should use 'm_afterreadscript' and
'm_beforewritescript' for client backends.
Okay.
Another possible issue is:
if we read a task in iCalendar2.0 format from client backend with a priority
and then send it in vCalendar1.0, then when refreshing from server, we might a
different priority value other than our sent and they should belong to one
category(high, normal, low). In some servers, if it has more than 3
categories,
like memotoo, which has 5 categories, very high, high, normal, low, very low,
this conversion could make some problems on its web page view.
I agree that loosing information isn't nice, but what can be done about it? If
the interchange format only has three levels, some information is inevitably
lost.
In the case of Memotoo, aren't we using iCalendar 2.0? In that case no
information should be lost.
--
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.
___
Syncevolution-issues mailing list
Syncevolution-issues@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6664] vCalendar 1.0: priorities of tasks not matched with other applications (Mobical)
http://bugzilla.moblin.org/show_bug.cgi?id=6664 --- Comment #7 from yongsheng zhu yongsheng@intel.com 2009-10-14 01:36:13 --- Doing the right thing by default sounds, eh, right. But I think we should give a backend the chance to override that. For example, it might use its own custom mapping for priorities despite using vCalendar 1.0. Yes, it's reasonable. I'll take care this. In the case of Memotoo, aren't we using iCalendar 2.0? In that case no information should be lost. Yes, Memotoo uses iCalendar2.0. Suppose below sync flow(syncs are one way): memotoo - client - mobical - client -memotoo Though a task is not changed anymore in the flow, its priority category might be changed. Here I raise this issue for the completeness of consideration. I think it is valuable to do this conversion. -- 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. ___ Syncevolution-issues mailing list Syncevolution-issues@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6499] sync-ui hangs when network gets disconnected
http://bugzilla.moblin.org/show_bug.cgi?id=6499 tshureih tariq.shur...@intel.com changed: What|Removed |Added Blocks||6796 -- 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. ___ Syncevolution-issues mailing list Syncevolution-issues@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6668] Mobical: PHOTO on server not shown on client (vCard 2.1)
http://bugzilla.moblin.org/show_bug.cgi?id=6668 --- Comment #4 from Chen Congwu congwu.c...@intel.com 2009-10-14 19:09:54 --- (In reply to comment #3) Therefore I am thinking work it at our side. I applied Lukas's commit to moblin synthesis repo against master branch. Pushed to congwu branch, did a rudimentary test, it worked well. -- 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. ___ Syncevolution-issues mailing list Syncevolution-issues@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6457] nightly testing + valgrind results
http://bugzilla.moblin.org/show_bug.cgi?id=6457 --- Comment #10 from yongsheng zhu yongsheng@intel.com 2009-10-14 20:05:41 --- (In reply to comment #9) ok, I'll add this and check the return code. thanks I have submitted the changes. waiting for test results. These should be done according to test results. -- 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. ___ Syncevolution-issues mailing list Syncevolution-issues@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution-issues
[Syncevolution-issues] [Bug 6664] vCalendar 1.0: priorities of tasks not matched with other applications (Mobical)
http://bugzilla.moblin.org/show_bug.cgi?id=6664 --- Comment #8 from yongsheng zhu yongsheng@intel.com 2009-10-14 20:13:33 --- Patrick, the 3 patches are ready. Please help review and merge them in branch 'origin/bug6664'. 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. ___ Syncevolution-issues mailing list Syncevolution-issues@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution-issues
