dbus-cplusplus-devel — Internal development and usage of the dbus-c++ API

Re: [dbus-cplusplus-devel] usage of toString() fails to compile

[Andreas V. <li...@br...>]

Am Tue, 20 Apr 2010 15:18:34 -0400 schrieb Jason Glasgow:

Yes, do this. It features the direct C++ object transport wrapper. It's
very comfortable to access it in this way and much easier to replace
Dbus-C++ in your application with another transport layer if ever
needed.

But note that the C++ object transport it's yet optimised for
throughput. So if you transport large vectors measure the data copy
loss! I've some ideas how to optimise this, but not yet had the time.

read this:
http://sourceforge.net/apps/trac/dbus-cplusplus/wiki/Introspection%20Format

regards
	Andreas

> Thanks for the update.  Sounds bad the fdo is such a pain.  We'll
> start looking at the gitorious code.
>  -Jason
> 
> On Tue, Apr 20, 2010 at 3:12 PM, Andreas Volz <li...@br...>
> wrote:
> 
> > Am Tue, 13 Apr 2010 18:01:04 -0400 schrieb Jason Glasgow:
> >
> > Hi,
> >
> > I would do it, but for some reasons I couldn't commit. It seems fdo
> > doesn't accept my ssh keys. It was the hell to get some commit
> > access from fdo. :-(
> >
> > Not sure if I've the time to trouble again with fdo to find the
> > problem. If I don't find a solution, development will continue in
> > gitorious branch only..

Re: [dbus-cplusplus-devel] usage of toString() fails to compile

[Andreas V. <li...@br...>]

Am Tue, 13 Apr 2010 18:01:04 -0400 schrieb Jason Glasgow:

Hi,

I would do it, but for some reasons I couldn't commit. It seems fdo
doesn't accept my ssh keys. It was the hell to get some commit access
from fdo. :-(

Not sure if I've the time to trouble again with fdo to find the
problem. If I don't find a solution, development will continue in
gitorious branch only..

regards
	Andreas

> Great. Thanks. -Jason
> 
> On Tue, Apr 13, 2010 at 5:29 PM, Andreas Volz <li...@br...>
> wrote:
> 
> > Am Tue, 6 Apr 2010 13:52:14 -0400 schrieb Jason Glasgow:
> >
> > Hello Jason,
> >
> > you're right. I forgot to merge something to the fdo branch. I'll
> > commit your patch slightly modified to both branches in the next
> > days. Thanks for the hint.
> >
> > regards
> >        Andreas
> >
> > > When building for the HEAD of the tree at git://
> > > anongit.freedesktop.org/git/dbus/dbus-c++/ I get the following
> > > error:
> > >
> > >  g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/dbus-1.0
> > > -I/usr/lib/dbus-1.0/include -I../include -I../include
> > > -fvisibility=hidden -Wall -O3 -MT eventloop-integration.lo -MD
> > > -MP -MF .deps/eventloop-integration.Tpo -c
> > > eventloop-integration.cpp  -fPIC -DPIC
> > > -o .libs/eventloop-integration.o In file included from
> > > eventloop-integration.cpp:30: ../include/dbus-c++/eventloop-integration.h:
> > > In constructor ‘DBus::BusDispatcher::BusDispatcher()’:
> > > ../include/dbus-c++/eventloop-integration.h:71: error: ‘toString’
> > > was not declared in this scope
> > > eventloop-integration.cpp: In member function ‘virtual void
> > > DBus::BusDispatcher::leave()’:
> > > eventloop-integration.cpp:93: error: ‘toString’ was not declared
> > > in this scope
> > > make[2]: *** [eventloop-integration.lo] Error 1
> > > make[2]: Leaving directory
> > >
> > `/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++/src'
> > > make[1]: *** [all-recursive] Error 1
> > > make[1]: Leaving directory
> > >
> > `/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++'
> > > make: *** [all] Error 2
> > >
> > >
> > > I have fixed this with the following patch.  Is this a known
> > > problem?  I am compiling on Ubuntu, but the problem also occurs
> > > in  a portage build environment.
> > >
> > > Thanks for any information.
> > > Jason Glasgow
> > >
> > >
> > > diff --git a/examples/echo/echo-client.cpp
> > > b/examples/echo/echo-client.cpp index 093595f..8fe7ad7 100644
> > > --- a/examples/echo/echo-client.cpp
> > > +++ b/examples/echo/echo-client.cpp
> > > @@ -6,6 +6,7 @@
> > >  #include <iostream>
> > >  #include <pthread.h>
> > >  #include <signal.h>
> > > +#include <stdio.h>
> > >
> > >  using namespace std;
> > >
> > > diff --git a/include/dbus-c++/eventloop-integration.h
> > > b/include/dbus-c++/eventloop-integration.h
> > > index fd56c6e..2579273 100644
> > > --- a/include/dbus-c++/eventloop-integration.h
> > > +++ b/include/dbus-c++/eventloop-integration.h
> > > @@ -26,6 +26,7 @@
> > >  #define __DBUSXX_EVENTLOOP_INTEGRATION_H
> > >
> > >  #include <errno.h>
> > > +#include <string.h>
> > >  #include "api.h"
> > >  #include "dispatcher.h"
> > >  #include "util.h"
> > > @@ -68,8 +69,12 @@ public:
> > >   //pipe to create a new fd used to unlock a dispatcher at any
> > >      // moment (used by leave function)
> > >   int ret = pipe(_pipe);
> > > - if (ret == -1) throw Error("PipeError:errno",
> > > toString(errno).c_str()); -
> > > + if (ret == -1) {
> > > +                  char buffer[128];
> > > +                  throw Error("PipeError:errno",
> > > strerror_r(errno,
> > > +
> > > buffer, +
> > >  sizeof(buffer)));
> > > +                }
> > >   _fdunlock[0] = _pipe[0];
> > >   _fdunlock[1] = _pipe[1];
> > >
> > > diff --git a/src/eventloop-integration.cpp
> > > b/src/eventloop-integration.cpp index d801574..53aea5f 100644
> > > --- a/src/eventloop-integration.cpp
> > > +++ b/src/eventloop-integration.cpp
> > > @@ -90,8 +90,12 @@ void BusDispatcher::leave()
> > >   _running = false;
> > >
> > >   int ret = write(_fdunlock[1],"exit",strlen("exit"));
> > > - if (ret == -1) throw Error("WriteError:errno",
> > > toString(errno).c_str()); -
> > > + if (ret == -1) {
> > > +          char buffer[128];
> > > +          throw Error("PipeError:errno", strerror_r(errno,
> > > +                                                    buffer,
> > > +
> > > sizeof(buffer)));
> > > +        }
> > >   close(_fdunlock[1]);
> > >   close(_fdunlock[0]);
> > >  }
> > > @@ -172,4 +176,3 @@ void BusDispatcher::watch_ready(DefaultWatch
> > > &ew)
> > >
> > >   watch->handle(flags);
> > >  }
> > > -
> >
> >
> > ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >

Re: [dbus-cplusplus-devel] usage of toString() fails to compile

[Andreas V. <li...@br...>]

Am Tue, 6 Apr 2010 13:52:14 -0400 schrieb Jason Glasgow:

Hello Jason,

you're right. I forgot to merge something to the fdo branch. I'll
commit your patch slightly modified to both branches in the next days.
Thanks for the hint.

regards
	Andreas

> When building for the HEAD of the tree at git://
> anongit.freedesktop.org/git/dbus/dbus-c++/ I get the following error:
> 
>  g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/dbus-1.0
> -I/usr/lib/dbus-1.0/include -I../include -I../include
> -fvisibility=hidden -Wall -O3 -MT eventloop-integration.lo -MD -MP -MF
> .deps/eventloop-integration.Tpo -c eventloop-integration.cpp  -fPIC
> -DPIC -o .libs/eventloop-integration.o
> In file included from eventloop-integration.cpp:30:
> ../include/dbus-c++/eventloop-integration.h: In constructor
> ‘DBus::BusDispatcher::BusDispatcher()’:
> ../include/dbus-c++/eventloop-integration.h:71: error: ‘toString’ was
> not declared in this scope
> eventloop-integration.cpp: In member function ‘virtual void
> DBus::BusDispatcher::leave()’:
> eventloop-integration.cpp:93: error: ‘toString’ was not declared in
> this scope
> make[2]: *** [eventloop-integration.lo] Error 1
> make[2]: Leaving directory
> `/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++'
> make: *** [all] Error 2
> 
> 
> I have fixed this with the following patch.  Is this a known
> problem?  I am compiling on Ubuntu, but the problem also occurs in  a
> portage build environment.
> 
> Thanks for any information.
> Jason Glasgow
> 
> 
> diff --git a/examples/echo/echo-client.cpp
> b/examples/echo/echo-client.cpp index 093595f..8fe7ad7 100644
> --- a/examples/echo/echo-client.cpp
> +++ b/examples/echo/echo-client.cpp
> @@ -6,6 +6,7 @@
>  #include <iostream>
>  #include <pthread.h>
>  #include <signal.h>
> +#include <stdio.h>
> 
>  using namespace std;
> 
> diff --git a/include/dbus-c++/eventloop-integration.h
> b/include/dbus-c++/eventloop-integration.h
> index fd56c6e..2579273 100644
> --- a/include/dbus-c++/eventloop-integration.h
> +++ b/include/dbus-c++/eventloop-integration.h
> @@ -26,6 +26,7 @@
>  #define __DBUSXX_EVENTLOOP_INTEGRATION_H
> 
>  #include <errno.h>
> +#include <string.h>
>  #include "api.h"
>  #include "dispatcher.h"
>  #include "util.h"
> @@ -68,8 +69,12 @@ public:
>   //pipe to create a new fd used to unlock a dispatcher at any
>      // moment (used by leave function)
>   int ret = pipe(_pipe);
> - if (ret == -1) throw Error("PipeError:errno",
> toString(errno).c_str()); -
> + if (ret == -1) {
> +                  char buffer[128];
> +                  throw Error("PipeError:errno", strerror_r(errno,
> +                                                            buffer,
> +
>  sizeof(buffer)));
> +                }
>   _fdunlock[0] = _pipe[0];
>   _fdunlock[1] = _pipe[1];
> 
> diff --git a/src/eventloop-integration.cpp
> b/src/eventloop-integration.cpp index d801574..53aea5f 100644
> --- a/src/eventloop-integration.cpp
> +++ b/src/eventloop-integration.cpp
> @@ -90,8 +90,12 @@ void BusDispatcher::leave()
>   _running = false;
> 
>   int ret = write(_fdunlock[1],"exit",strlen("exit"));
> - if (ret == -1) throw Error("WriteError:errno",
> toString(errno).c_str()); -
> + if (ret == -1) {
> +          char buffer[128];
> +          throw Error("PipeError:errno", strerror_r(errno,
> +                                                    buffer,
> +                                                    sizeof(buffer)));
> +        }
>   close(_fdunlock[1]);
>   close(_fdunlock[0]);
>  }
> @@ -172,4 +176,3 @@ void BusDispatcher::watch_ready(DefaultWatch &ew)
> 
>   watch->handle(flags);
>  }
> -

[dbus-cplusplus-devel] usage of toString() fails to compile

[Jason G. <jgl...@go...>]

When building for the HEAD of the tree at git://
anongit.freedesktop.org/git/dbus/dbus-c++/ I get the following error:

 g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I../include -I../include -fvisibility=hidden
-Wall -O3 -MT eventloop-integration.lo -MD -MP -MF
.deps/eventloop-integration.Tpo -c eventloop-integration.cpp  -fPIC -DPIC -o
.libs/eventloop-integration.o
In file included from eventloop-integration.cpp:30:
../include/dbus-c++/eventloop-integration.h: In constructor
‘DBus::BusDispatcher::BusDispatcher()’:
../include/dbus-c++/eventloop-integration.h:71: error: ‘toString’ was not
declared in this scope
eventloop-integration.cpp: In member function ‘virtual void
DBus::BusDispatcher::leave()’:
eventloop-integration.cpp:93: error: ‘toString’ was not declared in this
scope
make[2]: *** [eventloop-integration.lo] Error 1
make[2]: Leaving directory
`/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/local/google/home/jglasgow/chromeos-wednesday/chromeos/src/third_party/dbus-c++'
make: *** [all] Error 2


I have fixed this with the following patch.  Is this a known problem?  I am
compiling on Ubuntu, but the problem also occurs in  a portage build
environment.

Thanks for any information.
Jason Glasgow


diff --git a/examples/echo/echo-client.cpp b/examples/echo/echo-client.cpp
index 093595f..8fe7ad7 100644
--- a/examples/echo/echo-client.cpp
+++ b/examples/echo/echo-client.cpp
@@ -6,6 +6,7 @@
 #include <iostream>
 #include <pthread.h>
 #include <signal.h>
+#include <stdio.h>

 using namespace std;

diff --git a/include/dbus-c++/eventloop-integration.h
b/include/dbus-c++/eventloop-integration.h
index fd56c6e..2579273 100644
--- a/include/dbus-c++/eventloop-integration.h
+++ b/include/dbus-c++/eventloop-integration.h
@@ -26,6 +26,7 @@
 #define __DBUSXX_EVENTLOOP_INTEGRATION_H

 #include <errno.h>
+#include <string.h>
 #include "api.h"
 #include "dispatcher.h"
 #include "util.h"
@@ -68,8 +69,12 @@ public:
  //pipe to create a new fd used to unlock a dispatcher at any
     // moment (used by leave function)
  int ret = pipe(_pipe);
- if (ret == -1) throw Error("PipeError:errno", toString(errno).c_str());
-
+ if (ret == -1) {
+                  char buffer[128];
+                  throw Error("PipeError:errno", strerror_r(errno,
+                                                            buffer,
+
 sizeof(buffer)));
+                }
  _fdunlock[0] = _pipe[0];
  _fdunlock[1] = _pipe[1];

diff --git a/src/eventloop-integration.cpp b/src/eventloop-integration.cpp
index d801574..53aea5f 100644
--- a/src/eventloop-integration.cpp
+++ b/src/eventloop-integration.cpp
@@ -90,8 +90,12 @@ void BusDispatcher::leave()
  _running = false;

  int ret = write(_fdunlock[1],"exit",strlen("exit"));
- if (ret == -1) throw Error("WriteError:errno", toString(errno).c_str());
-
+ if (ret == -1) {
+          char buffer[128];
+          throw Error("PipeError:errno", strerror_r(errno,
+                                                    buffer,
+                                                    sizeof(buffer)));
+        }
  close(_fdunlock[1]);
  close(_fdunlock[0]);
 }
@@ -172,4 +176,3 @@ void BusDispatcher::watch_ready(DefaultWatch &ew)

  watch->handle(flags);
 }
-

Re: [dbus-cplusplus-devel] Reg. bug #26086

[Joe S. <js...@hi...>]

On Sat, 2010-01-30 at 10:14 +0100, Andreas Volz wrote:
> => Please attach a minimal example which shows the crash. Attach it
> here or in the ticket.

The issue happens in the example code (examples/hal/hal-listen).

> BTW: There's a tracker for bugs on sf.net. Because of this I didn't
> notice the bug.

I was not sure which tracker is being used currently. The sf.net tracker
was empty. So was the one on trac. Should I move this over to sf.net?

-- 
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in/

Re: [dbus-cplusplus-devel] Reg. bug #26086

[Andreas V. <li...@br...>]

Am Mon, 18 Jan 2010 03:39:54 +0530 schrieb Joe Steeve:

> Hello,
> 
> Can someone please look into bug #26086 on bugs.freedesktop.org.

I did a reply in the ticket...

=> Please attach a minimal example which shows the crash. Attach it
here or in the ticket.

BTW: There's a tracker for bugs on sf.net. Because of this I didn't
notice the bug.

regards
	Andreas

[dbus-cplusplus-devel] Reg. bug #26086

[Joe S. <js...@hi...>]

Hello,

Can someone please look into bug #26086 on bugs.freedesktop.org.

-- 
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in/

[dbus-cplusplus-devel] Reg. 'dataslot' in PendingCall::Private

[Joe S. <js...@hi...>]

Hello,

Shouldnt the destructor of PendingCall::Private (in pendingcall.cpp) be
calling 'dbus_pending_call_free_data_slot (&dataslot)' ??

-- 
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in/

Re: [dbus-cplusplus-devel] Setting dbus pending callback.

[Joe S. <js...@hi...>]

Hello Andreas,

On Sun, 2010-01-17 at 17:01 +0100, Andreas Volz wrote:
> sorry for the late answer. Why don't you simply use the XML
> introspection to generate your helper classes? It works like in the
> echo example.
> 
> Maybe you've a special reason not to do it like in the echo example...?

we need to integrate dbus-cplusplus to use our existing event loop
mechanism (select based). And, we cannot afford to block over I/O (even
client-side calls).

We have managed to implement the required "eventloop integration"
classes.

However lately we noticed that, we cannot be completely asynchronous as
libdbus does synchronous stuff under the hood ('dbus_bus_add_match',
'dbus_bus_remove_match' for example). I am clueless as to how much this
is going to affect the rest of the application :-S. So, currently i'm
trying to profile and see whether we can bear with this or whether we'll
have to put dbus related stuff on a thread.

-- 
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in/

Re: [dbus-cplusplus-devel] Setting dbus pending callback.

[Andreas V. <li...@br...>]

Am Wed, 30 Dec 2009 12:49:49 +0530 schrieb Vivek Anand:

Hello Vivek,

sorry for the late answer. Why don't you simply use the XML
introspection to generate your helper classes? It works like in the
echo example.

Maybe you've a special reason not to do it like in the echo example...?

regards
	Andreas

> Hello,
> 
> I want to use dbus-c++ for my application which has its own main
> loop. I want to do an asynchronous call. I found the method
> send_async in connection.cpp, but i dont know how to set the callback
> function for pending slot.
> for eg. I want to set a function "CallbackFn" for Pending.
> 
> Any help in this regard is appreciated.
> -- 
> Vivek Anand
> HiPro IT Solutions
> -- 
> Vivek Anand
> HiPro IT Solutions
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast
> and easy Join now and get one step closer to millions of Verizon
> customers http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Was my last reply received?  If not, I copied my reply and re-sending it.

Thanks,
Jay

-----------------------------------------------


From: Freyensee, James P
Sent: Wednesday, December 02, 2009 1:29 PM
To: Andreas Volz
Subject: RE: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Nope, actually I didn't see this email.  So thanks for sending this my way.

Our patch and change all works.  I can compile it and I am currently using it.  The caveat is I'm compiling it in Moblin.

I see:

Connection Connection::SystemBus(Dispatcher* dispatcher )
{
        return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);
}

in the libdbus-c++ code I'm using which we gave you the patch.  We use Connection::SystemBus(Dispatcher)
call a lot.

For example:

//new default dispatcher used by SystemBus() ...
dispatcher = new DBus::BusDispatcher();
try{
        DBus::Connection conn = DBus::Connection::SystemBus(dispatcher);
}

Now DBus::BusDispatcher() will return an object of 'BusDispatcher' which is in the DBus namespace and is a child of the public Dispatcher class.

The Dispatcher class looks like a base class that is inside the DBus namespace.

I think our Connection constructor is matching up with Connection constructor found in include/dbus-c++/connection.h:

class DXXAPI Connection
{
public:

        static Connection SystemBus(Dispatcher* dispatcher = default_dispatcher );

I also see:
       Connection(Private *, Dispatcher * dispatcher = default_dispatcher);

which is probably matching the Connection::SystemBus() call in question, the
"return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);", yes??

Jay

-----Original Message-----
From: Andreas Volz [mailto:li...@br...]
Sent: Wednesday, December 02, 2009 11:40 AM
To: Freyensee, James P
Subject: Fw: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Hello James,

did you get this E-Mail from the list?

regards
        Andreas

Anfang der weitergeleiteten Nachricht:

Datum: Sun, 29 Nov 2009 17:36:46 +0100
Sender: Andreas Volz <li...@br...>
Empfänger: dbu...@li...
Titel: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?


Am Fri, 20 Nov 2009 09:58:38 -0800 schrieb Freyensee, James P:

> On the examples, I don't think they are important.  I know changes
> were made just to get them to compile so if the examples compile for
> you, then that's good :-).

I didn't try it. I hope you'll give me feedback if it works for you.

> On:
> >connection.h/connection.cpp:
> >extern DXXAPI Dispatcher* default_dispatcher;
> >...and all changes specific to the change that Connection
> >constructors have a new parameter Dispatcher* dispatcher.
>
> >I've a raw idea what's the reason for it. But could you explain what
> >was the main idea behind this change.
>
> I cannot give you an exact reason, but I can give you a general
> reason.  We want a safeguard of being able to set up a single default
> dispatch mechanism for all Dbus connections we try to establish in a
> project.  For example, there is this project we have open-sourced for
> a 3rd party:
>
> https://sourceforge.net/projects/optelephony
>
> that heavily uses this concept when trying to establish an initial
> session with the 3rd party's product:
>
> // from https://sourceforge.net/projects/optelpehony
> bool TelSessionClient::initSessionClient(){
>
>    if(!mDispatcher){
>     mDispatcher = new DBus::Glib::BusDispatcher();
>     DBus::default_dispatcher = mDispatcher;
>     mDispatcher->attach(NULL);
>    }
>
>    if(!mConnection){
>     try{
>     mConnection = new DBus::Connection(DBus::Connection::SystemBus());
>     }
>     catch (DBus::Error e) {
>      printf("Can not connect to the SystemBus : %s\n",e.message());
>      return 0;
>     }
>     mConnection->set_timeout(120*1000);
>    }
>
>    if(!cb)
>     cb = new TelCallBack(*mConnection);
>
>    if(!server)
>     try{
>      server = new TelServerTAPI (*mConnection);
>     }
>     catch (DBus::Error e){
>      return false;
>     }
>    mDispatcher->enter();
>    return true;
> }

I've a little problem with this patch. See here:

before:
Connection Connection::SystemBus()
{
        return Connection(new Private(DBUS_BUS_SYSTEM));
}

after patch:
Connection Connection::SystemBus(Dispatcher* dispatcher )
{
        return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);
}


But look at Private:

        Private(DBusConnection *, Server::Private * = NULL);

        Private(DBusBusType);

In "Before" the second constructor with DBusBusType was called before.
But now you call a Constructor with (DBusBusType, Dispatcher*) what
doesn't seem to have such a constructor. I didn't compile your sources,
but does this compile? Or do I have some merging problem in Private
here?

> On:
> >generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
>
> >What are exactly the reason of these change? Looks for me like some
> >sort of Async method support. Could you spend some more words here?
>
> that actually did not come from the change we wanted to apply to your
> project.  What looks like has happened is these files used to be in
> xml2cpp.cpp and were separated out at some point.  I believe the
> commit ID on the git tree when this happened was c2b8cb (maybe??).  I
> don't think this is really a part of the libdbus-c++ functionality as
> is a part of a tool to create .cpp code from .xml code, so I don't
> believe this effects us at all.

Ok. Async support is on my TODO list. So I'll later take a look on it.

> On:
>
> > eventloop.cpp:
> > DefaultMutex::DefaultMutex()
> > {
>
> >   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >  _mutex = recmutex;
> > //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > //pthread_mutex_init(&_mutex, NULL);
> >}
>
> We don't seem to use the class DefaultMutex or the methods where the
> DefaultMutex instance variable _mutex_p is used (queue_connection(),
> dispatch_pending()).  And I know we did not comment that code out.  I
> could tell you a possible reason for why
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there.  It prevents a
> certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used
> instead.  If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple
> calls of pthread_mutex_lock without calling pthread_mutex_unlock by
> the owner of the mutex could result in dead-lock.  I have no idea if
> the original intent was to be able to use this code recursively, but
> it may be a good idea to leave this alone (well, with the exception
> of removing the commented-out lines)?

I reviewed the code and couldn't see a reason for using the recursive
mutex code here. So I just did this:

        DefaultMutex(bool recursive = false);

DefaultMutex::DefaultMutex(bool recursive)
{
        if (recursive)
        {
                pthread_mutex_t recmutex =
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; _mutex = recmutex;
        }
        else
        {
                pthread_mutex_init(&_mutex, NULL);
        }
}

So as default we've the old implementation. If you ever see a problem
with it we may change to the recursive mutex as default. Is this ok for
you? How ever, I commited this.

regards
        Andreas Volz
----------------------------------------------------------------------

Message: 1
Date: Fri, 20 Nov 2009 09:58:38 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
        project...best way?
To: "dbu...@li..."
        <dbu...@li...>
Cc: "Yokoyama, Caz" <caz...@in...>
Message-ID:
        <A26...@or...>

Content-Type: text/plain; charset="us-ascii"

Andreas:

Thanks for your work.  It is very much appreciated.

On the examples, I don't think they are important.  I know changes were made just to get them to compile so if the examples compile for you, then that's good :-).


On:
>connection.h/connection.cpp:
>extern DXXAPI Dispatcher* default_dispatcher;
>...and all changes specific to the change that Connection constructors
>have a new parameter Dispatcher* dispatcher.

>I've a raw idea what's the reason for it. But could you explain what
>was the main idea behind this change.

I cannot give you an exact reason, but I can give you a general reason.  We want a safeguard of being able to set up a single default dispatch mechanism for all Dbus connections we try to establish in a project.  For example, there is this project we have open-sourced for a 3rd party:

https://sourceforge.net/projects/optelephony

that heavily uses this concept when trying to establish an initial session with the 3rd party's product:

// from https://sourceforge.net/projects/optelpehony
bool TelSessionClient::initSessionClient(){

   if(!mDispatcher){
    mDispatcher = new DBus::Glib::BusDispatcher();
    DBus::default_dispatcher = mDispatcher;
    mDispatcher->attach(NULL);
   }

   if(!mConnection){
    try{
    mConnection = new DBus::Connection(DBus::Connection::SystemBus());
    }
    catch (DBus::Error e) {
     printf("Can not connect to the SystemBus : %s\n",e.message());
     return 0;
    }
    mConnection->set_timeout(120*1000);
   }

   if(!cb)
    cb = new TelCallBack(*mConnection);

   if(!server)
    try{
     server = new TelServerTAPI (*mConnection);
    }
    catch (DBus::Error e){
     return false;
    }
   mDispatcher->enter();
   return true;
}

On:
>generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

>What are exactly the reason of these change? Looks for me like some sort
>of Async method support. Could you spend some more words here?

that actually did not come from the change we wanted to apply to your project.  What looks like has happened is these files used to be in xml2cpp.cpp and were separated out at some point.  I believe the commit ID on the git tree when this happened was c2b8cb (maybe??).  I don't think this is really a part of the libdbus-c++ functionality as is a part of a tool to create .cpp code from .xml code, so I don't believe this effects us at all.

On:

> eventloop.cpp:
> DefaultMutex::DefaultMutex()
> {

>   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>  _mutex = recmutex;
> //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> //pthread_mutex_init(&_mutex, NULL);
>}

We don't seem to use the class DefaultMutex or the methods where the DefaultMutex instance variable _mutex_p is used (queue_connection(), dispatch_pending()).  And I know we did not comment that code out.  I could tell you a possible reason for why PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there.  It prevents a certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used instead.  If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple calls of pthread_mutex_lock without calling pthread_mutex_unlock by the owner of the mutex could result in dead-lock.  I have no idea if the original intent was to be able to use this code recursively, but it may be a good idea to leave this alone (well, with the exception of removing the commented-out lines)?


I think I covered all of your concerns??  Please let me know if I did not.  Also, please let me know when the final changes are made.  I'm going to pull down the final result and run it with our project.

thanks again,
Jay

------------------------------

Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.

I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):

examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)

connection.h/connection.cpp:

extern DXXAPI Dispatcher* default_dispatcher;

...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.

I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.

connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied


eventloop.cpp:
DefaultMutex::DefaultMutex()
{

   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
  _mutex = recmutex;
 //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 //pthread_mutex_init(&_mutex, NULL);
}

What was the reason of doing this?

The rest of the eventloop integration is applied now.

generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?

regards
 Andreas

-----Original Message-----
From: dbu...@li... [mailto:dbu...@li...]
Sent: Tuesday, November 17, 2009 4:06 AM
To: dbu...@li...
Subject: dbus-cplusplus-devel Digest, Vol 16, Issue 5

Send dbus-cplusplus-devel mailing list submissions to
 dbu...@li...

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
or, via email, send a message with subject or body 'help' to
 dbu...@li...

You can reach the person managing the list at
 dbu...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dbus-cplusplus-devel digest..."


Today's Topics:

   1. Re: contributing a submission to the project...best way?
      (Andreas Volz)
   2. Re: contributing a submission to the project...best way?
      (Freyensee, James P)
   3. Re: contributing a submission to the project...best way?
      (Freyensee, James P)
   4. Re: contributing a submission to the project...best way?
      (Andreas Volz)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Nov 2009 18:45:34 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: "Freyensee, James P" <jam...@in...>
Cc: "Yokoyama, CazX" <caz...@in...>, "Ahmed, Suhail"
 <suh...@in...>, "Benis, Robertino"
 <rob...@in...>,
 dbu...@li...
Message-ID: <20091116184534.6c4b2b02@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
 Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>  project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>  Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 2
Date: Mon, 16 Nov 2009 10:07:25 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: Andreas Volz <li...@br...>
Cc: "Yokoyama, Caz" <caz...@in...>, "Ahmed, Suhail"
 <suh...@in...>, "Benis,  Robertino"
 <rob...@in...>,
 "dbu...@li..."
 <dbu...@li...>
Message-ID:
 <5CF...@or...>

Content-Type: text/plain; charset="us-ascii"

Thanks Andreas for looking at this and letting me know.

I was unaware of that sourceforge bug; but it looks like those are the functions we added in this bug and need.


Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 3
Date: Mon, 16 Nov 2009 10:39:06 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: Andreas Volz <li...@br...>
Cc: "Ahmed, Suhail" <suh...@in...>, "Yokoyama, Caz"
 <caz...@in...>, "Benis,  Robertino"
 <rob...@in...>,
 "dbu...@li..."
 <dbu...@li...>
Message-ID:
 <5CF...@or...>

Content-Type: text/plain; charset="us-ascii"

Andreas:

I am looking at the difference between the two patches.  There is a difference in how send_blocking() is getting patched.  The sourceforge patch, bug 2701443, changes how the send_blocking() call is used:

        static void unregister_function_stub( DBusConnection*, void* );
@@ -323,7 +331,7 @@ Message ObjectProxy::_invoke_method( Cal
        call.path(path().c_str());
        call.destination(service().c_str());

-       return conn().send_blocking(call);
+       return conn().send_blocking(call, get_timeout());

but nowhere in the patch is the send_blocking() call modified to reflect the new parameter 'get_timeout()'.  So either send_blocking()'s 2nd parameter in the gitorious branch is already there or there is another patch to add the send_blocking() second parameter.

Our patch makes an adjustment to send_blocking() :

@@ -360,7 +361,11 @@ Message Connection::send_blocking(Message &msg, int timeout)
  DBusMessage *reply;
  InternalError e;

+ if(this->_timeout != -1)
+ reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, this->_timeout, e);
+ else
  reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, timeout, e);
+



Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.

I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):

examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)

connection.h/connection.cpp:

extern DXXAPI Dispatcher* default_dispatcher;

...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.

I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.

connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied


eventloop.cpp:
DefaultMutex::DefaultMutex()
{

   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
  _mutex = recmutex;
 //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 //pthread_mutex_init(&_mutex, NULL);
}

What was the reason of doing this?

The rest of the eventloop integration is applied now.

generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?

regards
 Andreas





------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel


End of dbus-cplusplus-devel Digest, Vol 16, Issue 5
***************************************************



------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel


End of dbus-cplusplus-devel Digest, Vol 16, Issue 6
***************************************************

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Andreas:

Was the feedback I gave in the last thread okay with you? Anything I need to do for you?  Were the remaining changes accepted?  

Thanks!
Jay


----------------------------------------------------------------------

Message: 1
Date: Fri, 20 Nov 2009 09:58:38 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
	project...best way?
To: "dbu...@li..."
	<dbu...@li...>
Cc: "Yokoyama, Caz" <caz...@in...>
Message-ID:
	<A26...@or...>
	
Content-Type: text/plain; charset="us-ascii"

Andreas:

Thanks for your work.  It is very much appreciated.

On the examples, I don't think they are important.  I know changes were made just to get them to compile so if the examples compile for you, then that's good :-).


On:
>connection.h/connection.cpp:
>extern DXXAPI Dispatcher* default_dispatcher;
>...and all changes specific to the change that Connection constructors
>have a new parameter Dispatcher* dispatcher.

>I've a raw idea what's the reason for it. But could you explain what
>was the main idea behind this change.

I cannot give you an exact reason, but I can give you a general reason.  We want a safeguard of being able to set up a single default dispatch mechanism for all Dbus connections we try to establish in a project.  For example, there is this project we have open-sourced for a 3rd party:

https://sourceforge.net/projects/optelephony

that heavily uses this concept when trying to establish an initial session with the 3rd party's product:

// from https://sourceforge.net/projects/optelpehony
bool TelSessionClient::initSessionClient(){

   if(!mDispatcher){
    mDispatcher = new DBus::Glib::BusDispatcher();
    DBus::default_dispatcher = mDispatcher;
    mDispatcher->attach(NULL);
   }

   if(!mConnection){
    try{
    mConnection = new DBus::Connection(DBus::Connection::SystemBus());
    }
    catch (DBus::Error e) {
     printf("Can not connect to the SystemBus : %s\n",e.message());
     return 0;
    }
    mConnection->set_timeout(120*1000);
   }

   if(!cb)
    cb = new TelCallBack(*mConnection);

   if(!server)
    try{
     server = new TelServerTAPI (*mConnection);
    }
    catch (DBus::Error e){
     return false;
    }
   mDispatcher->enter();
   return true;
}

On:
>generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

>What are exactly the reason of these change? Looks for me like some sort
>of Async method support. Could you spend some more words here?

that actually did not come from the change we wanted to apply to your project.  What looks like has happened is these files used to be in xml2cpp.cpp and were separated out at some point.  I believe the commit ID on the git tree when this happened was c2b8cb (maybe??).  I don't think this is really a part of the libdbus-c++ functionality as is a part of a tool to create .cpp code from .xml code, so I don't believe this effects us at all.

On:

> eventloop.cpp:
> DefaultMutex::DefaultMutex()
> {

>   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>  _mutex = recmutex;
> //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> //pthread_mutex_init(&_mutex, NULL);
>}

We don't seem to use the class DefaultMutex or the methods where the DefaultMutex instance variable _mutex_p is used (queue_connection(), dispatch_pending()).  And I know we did not comment that code out.  I could tell you a possible reason for why PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there.  It prevents a certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used instead.  If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple calls of pthread_mutex_lock without calling pthread_mutex_unlock by the owner of the mutex could result in dead-lock.  I have no idea if the original intent was to be able to use this code recursively, but it may be a good idea to leave this alone (well, with the exception of removing the commented-out lines)?


I think I covered all of your concerns??  Please let me know if I did not.  Also, please let me know when the final changes are made.  I'm going to pull down the final result and run it with our project.

thanks again,
Jay

------------------------------

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Andreas V. <li...@br...>]

Am Fri, 20 Nov 2009 09:58:38 -0800 schrieb Freyensee, James P:

> On the examples, I don't think they are important.  I know changes
> were made just to get them to compile so if the examples compile for
> you, then that's good :-).

I didn't try it. I hope you'll give me feedback if it works for you.

> On:
> >connection.h/connection.cpp:
> >extern DXXAPI Dispatcher* default_dispatcher;
> >...and all changes specific to the change that Connection
> >constructors have a new parameter Dispatcher* dispatcher.
> 
> >I've a raw idea what's the reason for it. But could you explain what
> >was the main idea behind this change.
> 
> I cannot give you an exact reason, but I can give you a general
> reason.  We want a safeguard of being able to set up a single default
> dispatch mechanism for all Dbus connections we try to establish in a
> project.  For example, there is this project we have open-sourced for
> a 3rd party:
> 
> https://sourceforge.net/projects/optelephony
> 
> that heavily uses this concept when trying to establish an initial
> session with the 3rd party's product:
> 
> // from https://sourceforge.net/projects/optelpehony
> bool TelSessionClient::initSessionClient(){
> 
>    if(!mDispatcher){
>     mDispatcher = new DBus::Glib::BusDispatcher();
>     DBus::default_dispatcher = mDispatcher;
>     mDispatcher->attach(NULL);
>    }
> 
>    if(!mConnection){
>     try{
>     mConnection = new DBus::Connection(DBus::Connection::SystemBus());
>     }
>     catch (DBus::Error e) {
>      printf("Can not connect to the SystemBus : %s\n",e.message());
>      return 0;
>     }
>     mConnection->set_timeout(120*1000);
>    }
> 
>    if(!cb)
>     cb = new TelCallBack(*mConnection);
> 
>    if(!server)
>     try{
>      server = new TelServerTAPI (*mConnection);
>     }
>     catch (DBus::Error e){
>      return false;
>     }
>    mDispatcher->enter();
>    return true;
> }

I've a little problem with this patch. See here:

before:
Connection Connection::SystemBus()
{
	return Connection(new Private(DBUS_BUS_SYSTEM));
}

after patch:
Connection Connection::SystemBus(Dispatcher* dispatcher )
{
	return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);
}


But look at Private:

	Private(DBusConnection *, Server::Private * = NULL);

	Private(DBusBusType);

In "Before" the second constructor with DBusBusType was called before.
But now you call a Constructor with (DBusBusType, Dispatcher*) what
doesn't seem to have such a constructor. I didn't compile your sources,
but does this compile? Or do I have some merging problem in Private
here?

> On:
> >generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
> 
> >What are exactly the reason of these change? Looks for me like some
> >sort of Async method support. Could you spend some more words here?
> 
> that actually did not come from the change we wanted to apply to your
> project.  What looks like has happened is these files used to be in
> xml2cpp.cpp and were separated out at some point.  I believe the
> commit ID on the git tree when this happened was c2b8cb (maybe??).  I
> don't think this is really a part of the libdbus-c++ functionality as
> is a part of a tool to create .cpp code from .xml code, so I don't
> believe this effects us at all.

Ok. Async support is on my TODO list. So I'll later take a look on it.

> On:
> 
> > eventloop.cpp:
> > DefaultMutex::DefaultMutex()
> > {
> 
> >   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> >  _mutex = recmutex;
> > //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > //pthread_mutex_init(&_mutex, NULL);
> >}
> 
> We don't seem to use the class DefaultMutex or the methods where the
> DefaultMutex instance variable _mutex_p is used (queue_connection(),
> dispatch_pending()).  And I know we did not comment that code out.  I
> could tell you a possible reason for why
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there.  It prevents a
> certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used
> instead.  If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple
> calls of pthread_mutex_lock without calling pthread_mutex_unlock by
> the owner of the mutex could result in dead-lock.  I have no idea if
> the original intent was to be able to use this code recursively, but
> it may be a good idea to leave this alone (well, with the exception
> of removing the commented-out lines)?

I reviewed the code and couldn't see a reason for using the recursive
mutex code here. So I just did this:

	DefaultMutex(bool recursive = false);

DefaultMutex::DefaultMutex(bool recursive)
{
	if (recursive)
	{
		pthread_mutex_t recmutex =
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; _mutex = recmutex;
	}
	else
	{
		pthread_mutex_init(&_mutex, NULL);
	}
}

So as default we've the old implementation. If you ever see a problem
with it we may change to the recursive mutex as default. Is this ok for
you? How ever, I commited this.

regards
	Andreas Volz

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Andreas:

Thanks for your work.  It is very much appreciated.

On the examples, I don't think they are important.  I know changes were made just to get them to compile so if the examples compile for you, then that's good :-).


On:
>connection.h/connection.cpp:
>extern DXXAPI Dispatcher* default_dispatcher;
>...and all changes specific to the change that Connection constructors
>have a new parameter Dispatcher* dispatcher.

>I've a raw idea what's the reason for it. But could you explain what
>was the main idea behind this change.

I cannot give you an exact reason, but I can give you a general reason.  We want a safeguard of being able to set up a single default dispatch mechanism for all Dbus connections we try to establish in a project.  For example, there is this project we have open-sourced for a 3rd party:

https://sourceforge.net/projects/optelephony

that heavily uses this concept when trying to establish an initial session with the 3rd party's product:

// from https://sourceforge.net/projects/optelpehony
bool TelSessionClient::initSessionClient(){

   if(!mDispatcher){
    mDispatcher = new DBus::Glib::BusDispatcher();
    DBus::default_dispatcher = mDispatcher;
    mDispatcher->attach(NULL);
   }

   if(!mConnection){
    try{
    mConnection = new DBus::Connection(DBus::Connection::SystemBus());
    }
    catch (DBus::Error e) {
     printf("Can not connect to the SystemBus : %s\n",e.message());
     return 0;
    }
    mConnection->set_timeout(120*1000);
   }

   if(!cb)
    cb = new TelCallBack(*mConnection);

   if(!server)
    try{
     server = new TelServerTAPI (*mConnection);
    }
    catch (DBus::Error e){
     return false;
    }
   mDispatcher->enter();
   return true;
}

On:
>generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

>What are exactly the reason of these change? Looks for me like some sort
>of Async method support. Could you spend some more words here?

that actually did not come from the change we wanted to apply to your project.  What looks like has happened is these files used to be in xml2cpp.cpp and were separated out at some point.  I believe the commit ID on the git tree when this happened was c2b8cb (maybe??).  I don't think this is really a part of the libdbus-c++ functionality as is a part of a tool to create .cpp code from .xml code, so I don't believe this effects us at all.

On:

> eventloop.cpp:
> DefaultMutex::DefaultMutex()
> {

>   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>  _mutex = recmutex;
> //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> //pthread_mutex_init(&_mutex, NULL);
>}

We don't seem to use the class DefaultMutex or the methods where the DefaultMutex instance variable _mutex_p is used (queue_connection(), dispatch_pending()).  And I know we did not comment that code out.  I could tell you a possible reason for why PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there.  It prevents a certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used instead.  If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple calls of pthread_mutex_lock without calling pthread_mutex_unlock by the owner of the mutex could result in dead-lock.  I have no idea if the original intent was to be able to use this code recursively, but it may be a good idea to leave this alone (well, with the exception of removing the commented-out lines)?


I think I covered all of your concerns??  Please let me know if I did not.  Also, please let me know when the final changes are made.  I'm going to pull down the final result and run it with our project.

thanks again,
Jay

------------------------------

Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.

I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):

examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)

connection.h/connection.cpp:

extern DXXAPI Dispatcher* default_dispatcher;

...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.

I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.

connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied


eventloop.cpp:
DefaultMutex::DefaultMutex()
{

   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
  _mutex = recmutex;
 //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 //pthread_mutex_init(&_mutex, NULL);
}

What was the reason of doing this?

The rest of the eventloop integration is applied now.

generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?

regards
 Andreas

-----Original Message-----
From: dbu...@li... [mailto:dbu...@li...]
Sent: Tuesday, November 17, 2009 4:06 AM
To: dbu...@li...
Subject: dbus-cplusplus-devel Digest, Vol 16, Issue 5

Send dbus-cplusplus-devel mailing list submissions to
 dbu...@li...

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
or, via email, send a message with subject or body 'help' to
 dbu...@li...

You can reach the person managing the list at
 dbu...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dbus-cplusplus-devel digest..."


Today's Topics:

   1. Re: contributing a submission to the project...best way?
      (Andreas Volz)
   2. Re: contributing a submission to the project...best way?
      (Freyensee, James P)
   3. Re: contributing a submission to the project...best way?
      (Freyensee, James P)
   4. Re: contributing a submission to the project...best way?
      (Andreas Volz)


----------------------------------------------------------------------

Message: 1
Date: Mon, 16 Nov 2009 18:45:34 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: "Freyensee, James P" <jam...@in...>
Cc: "Yokoyama, CazX" <caz...@in...>, "Ahmed, Suhail"
 <suh...@in...>, "Benis, Robertino"
 <rob...@in...>,
 dbu...@li...
Message-ID: <20091116184534.6c4b2b02@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
 Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>  project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>  Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 2
Date: Mon, 16 Nov 2009 10:07:25 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: Andreas Volz <li...@br...>
Cc: "Yokoyama, Caz" <caz...@in...>, "Ahmed, Suhail"
 <suh...@in...>, "Benis,  Robertino"
 <rob...@in...>,
 "dbu...@li..."
 <dbu...@li...>
Message-ID:
 <5CF...@or...>

Content-Type: text/plain; charset="us-ascii"

Thanks Andreas for looking at this and letting me know.

I was unaware of that sourceforge bug; but it looks like those are the functions we added in this bug and need.


Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 3
Date: Mon, 16 Nov 2009 10:39:06 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: Andreas Volz <li...@br...>
Cc: "Ahmed, Suhail" <suh...@in...>, "Yokoyama, Caz"
 <caz...@in...>, "Benis,  Robertino"
 <rob...@in...>,
 "dbu...@li..."
 <dbu...@li...>
Message-ID:
 <5CF...@or...>

Content-Type: text/plain; charset="us-ascii"

Andreas:

I am looking at the difference between the two patches.  There is a difference in how send_blocking() is getting patched.  The sourceforge patch, bug 2701443, changes how the send_blocking() call is used:

        static void unregister_function_stub( DBusConnection*, void* );
@@ -323,7 +331,7 @@ Message ObjectProxy::_invoke_method( Cal
        call.path(path().c_str());
        call.destination(service().c_str());

-       return conn().send_blocking(call);
+       return conn().send_blocking(call, get_timeout());

but nowhere in the patch is the send_blocking() call modified to reflect the new parameter 'get_timeout()'.  So either send_blocking()'s 2nd parameter in the gitorious branch is already there or there is another patch to add the send_blocking() second parameter.

Our patch makes an adjustment to send_blocking() :

@@ -360,7 +361,11 @@ Message Connection::send_blocking(Message &msg, int timeout)
  DBusMessage *reply;
  InternalError e;

+ if(this->_timeout != -1)
+ reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, this->_timeout, e);
+ else
  reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, timeout, e);
+



Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >




------------------------------

Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
 project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.

I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):

examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)

connection.h/connection.cpp:

extern DXXAPI Dispatcher* default_dispatcher;

...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.

I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.

connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied


eventloop.cpp:
DefaultMutex::DefaultMutex()
{

   pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
  _mutex = recmutex;
 //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 //pthread_mutex_init(&_mutex, NULL);
}

What was the reason of doing this?

The rest of the eventloop integration is applied now.

generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?

regards
 Andreas





------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel


End of dbus-cplusplus-devel Digest, Vol 16, Issue 5
***************************************************

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Andreas V. <li...@br...>]

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title. 

I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):

examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)

connection.h/connection.cpp:

extern DXXAPI Dispatcher* default_dispatcher;

...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.

I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.

connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied


eventloop.cpp:
DefaultMutex::DefaultMutex()
{
	
	 	pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; 
 	_mutex = recmutex;
	//_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
	//pthread_mutex_init(&_mutex, NULL);
}

What was the reason of doing this?

The rest of the eventloop integration is applied now.

generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:

What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?

regards
	Andreas

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Andreas:

I am looking at the difference between the two patches.  There is a difference in how send_blocking() is getting patched.  The sourceforge patch, bug 2701443, changes how the send_blocking() call is used:

        static void unregister_function_stub( DBusConnection*, void* );
@@ -323,7 +331,7 @@ Message ObjectProxy::_invoke_method( Cal
        call.path(path().c_str());
        call.destination(service().c_str());

-       return conn().send_blocking(call);
+       return conn().send_blocking(call, get_timeout());

but nowhere in the patch is the send_blocking() call modified to reflect the new parameter 'get_timeout()'.  So either send_blocking()'s 2nd parameter in the gitorious branch is already there or there is another patch to add the send_blocking() second parameter.

Our patch makes an adjustment to send_blocking() :

@@ -360,7 +361,11 @@ Message Connection::send_blocking(Message &msg, int timeout)
 	DBusMessage *reply;
 	InternalError e;
 	
+	if(this->_timeout != -1)
+	reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, this->_timeout, e);
+	else
 	reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, timeout, e);
+	



Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Thanks Andreas for looking at this and letting me know.

I was unaware of that sourceforge bug; but it looks like those are the functions we added in this bug and need.


Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
        Andreas

>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
>       project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
>       Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Andreas V. <li...@br...>]

Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:

Hello James,

ok, I found the ticket:

https://bugs.freedesktop.org/show_bug.cgi?id=25022

There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:

http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B

I wonder because there's a similar ticket on sf.net:

http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684

Are those two tickets connected?

It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...

regards
	Andreas

> 
> Andreas:
> 
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project.  We verified the merge (from freedesktop)
> works, at least for the product we are using with it.  We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title. 
> 
> Thanks,
> Jay
>   
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
> 	project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
> 
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
> 
> Hello Jay,
> 
> Great to hear that someone likes to contribute some code.
> 
> It happens not that often that someone contributes code. So there's
> not really a process for it.
> 
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
> 
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
> 
> regards
> 	Andreas
> 
> > Andreas at al:
> > 
> > I have a co-worker who would like to make an addition to the
> > project.  What is the best way to do this?  I read on the website we
> > would submit the patch through Bugzilla.  Is this still correct?  Or
> > should we send the patch to this email list?
> > 
> > Second question- what would be the best way for us to create the
> > patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> > 
> > Thanks for your time.
> > 
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> > 

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Andreas:

A co-worker of mine just submitted bug 25022 that contains our addition to the project.  We verified the merge (from freedesktop) works, at least for the product we are using with it.  We did not see a category for "dbus-c++" so we filed it under "dbus" but stuck "dbuc-c++" in the Title. 

Thanks,
Jay
  

----------------------------------------------------------------------

Message: 1
Date: Sat, 7 Nov 2009 22:12:51 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
	project...best way?
To: dbu...@li...
Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII

Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:

Hello Jay,

Great to hear that someone likes to contribute some code.

It happens not that often that someone contributes code. So there's not
really a process for it.

I would prefer a patch through Bugzilla and a mail on the list pointing
to this Bugzilla entry. The prefered format is "git diff".

And most important, don't forget to tell me if the patch is on top of
the freedesktop repository or the gitorious repository.

regards
	Andreas

> Andreas at al:
> 
> I have a co-worker who would like to make an addition to the
> project.  What is the best way to do this?  I read on the website we
> would submit the patch through Bugzilla.  Is this still correct?  Or
> should we send the patch to this email list?
> 
> Second question- what would be the best way for us to create the
> patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> 
> Thanks for your time.
> 
> Respectfully,
> Jay Freyensee
> UMG
> (apologize in advance on email syntax; broken collarbone)
> 



------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

------------------------------

_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel


End of dbus-cplusplus-devel Digest, Vol 16, Issue 3
***************************************************

Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?

[Andreas V. <li...@br...>]

Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:

Hello Jay,

Great to hear that someone likes to contribute some code.

It happens not that often that someone contributes code. So there's not
really a process for it.

I would prefer a patch through Bugzilla and a mail on the list pointing
to this Bugzilla entry. The prefered format is "git diff".

And most important, don't forget to tell me if the patch is on top of
the freedesktop repository or the gitorious repository.

regards
	Andreas

> Andreas at al:
> 
> I have a co-worker who would like to make an addition to the
> project.  What is the best way to do this?  I read on the website we
> would submit the patch through Bugzilla.  Is this still correct?  Or
> should we send the patch to this email list?
> 
> Second question- what would be the best way for us to create the
> patch for you?  Use 'git format-patch'?  Normal 'diff' command?
> 
> Thanks for your time.
> 
> Respectfully,
> Jay Freyensee
> UMG
> (apologize in advance on email syntax; broken collarbone)
> 

[dbus-cplusplus-devel] contributing a submission to the project...best way?

[Freyensee, J. P <jam...@in...>]

Andreas at al:

I have a co-worker who would like to make an addition to the project.  What is the best way to do this?  I read on the website we would submit the patch through Bugzilla.  Is this still correct?  Or should we send the patch to this email list?

Second question- what would be the best way for us to create the patch for you?  Use 'git format-patch'?  Normal 'diff' command?

Thanks for your time.

Respectfully,
Jay Freyensee
UMG
(apologize in advance on email syntax; broken collarbone)

Re: [dbus-cplusplus-devel] dbus_bus_request_name with bluez

[Andreas V. <li...@br...>]

Am Fri, 30 Oct 2009 19:33:48 -0400 (EDT) schrieb John Palmieri:

> > BTW: I just found out if I start my application as root it also
> > works with enabled exception handling. Have I found a security hole
> > (at least
> > in dbus-python and dbus-send)?
> > 
> > bluez-4.12-0ubuntu5
> 
> Wait, I don't understand.  Are you developing dbus-c++ or are you
> just using dbus-c++?  Why is request_name being called? Requesting a
> name on a connection means you want to register that connection under
> the given common name.  Since bluez already has that name then you
> generate a D-Bus error.  None of the code above, either dbus-send or
> the python code ever calls request_name on the bluez common name so
> you wouldn't get that error. dbus-c++ for some reason is calling
> request_name when it shouldn't or you are using the C++ code wrong.
> Perhaps there is two different connections - one if you want to
> provide a service and another for clients wishing to connect to a
> service?  I've never used them so I am not completely sure.

I develop dbus-c++, but as I didn't start the project I don't know all
technical details. Here I copied a wrong example and wondered why it
doesn't work. As you see in my other post the problem is solved. :-)

regards
	Andreas

Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

[Randell J. <rj...@wg...>]

>In the past week I worked on the echo example and tried to figure out
>why it did not work.
>
>It occurred to me that the multi threading cannot work since libdbus
>does a poll and dbus-cplusplus does a poll as well on the same file
>descriptor which cannot be safe.
>
>My echo-client blocked for 25 secs after a client issued a Hello
>request. The server's response let the dispatcher return from the poll
>call. The following watch_ready read the message from the socket but had
>it not ready to dispatch before the client issued its blocking poll.
>Then the response was ready but the client could not be woken up.
>
>My first idea was that we must somehow be able to wake up the client,
>then I realized that this code was located in libdbus. The second idea
>was to have a separate connection for each server and client object.
>
>To ensure that the dispatcher is not polling the client connections and
>accidentally receive responses an additional dummy dispatcher must be
>created and set as default_dispatcher while creating the client
>connections.
>
>Please have a look at my patch.
>It fixed the echo example for me.

The patch didn't seem to be attached - where can it be found?  Can you
send it directly for me to try?

I've noticed problems before with 25-second delays when starting up a
dbus-c++ server in response to a dbus method.

Following is what I wrote on Sep 17th.  From what you're saying, the
problem may not be caused by a timing hole, and there's no retry -
what's probably happening is a following watch-ready is kicking things
off.

I worked around the problem (painfully) by waiting for a signal from the
service before sending it a method.

  Randell

From: Randell Jesup <rj...@wg...>
Subject: Problem with waiting for a service to be available
To: db...@li...
Date: Thu, 17 Sep 2009 17:09:31 -0400

There seems to be a designed-in timing hole in the DBus architecture, or
perhaps it isn't obvious (or explained) how you're supposed to wait for
a service to be available.  Note that "ServiceName" is using dbus-c++
(the working "git" tree branch with ecore integration).  Perhaps even
it's a dbus-c++ issue, though it doesn't seem like it.


If (like Qt's wrapper does to update ::isValid()) your application
watches for NameOwnerChanged to know when a destination is available to
send methods to, the ordering of operations leaves a timing hole.  To
whit:

(From what dbus-monitor sees, what my Qt apps sees, and what another
application would probably see):

:1.17 sends AddMatch to DBus for NameOwnerChanged signal

Assumes: we've connected NameOwnerChanged signal to internal Qt slot
Time goes by, and then we start up the server for ServiceName

signal NameOwnerChanged for :1.35
:1.35 sends Hello to DBus
signal NameOwnerChanged for ServiceName
:1.35 sends RequestName to DBus for ServiceName

At this point, the listener notices NameOwnerChanged, and sends a method
(init()) to to ServiceName.  Note that it may do this as soon as
NameOwnerChanged for ServiceName is delivered to :1.17

:1.17 sends init to Servicename
:1.35 sends AddMatch to DBus for ServiceName

Wait around 15-30 seconds....

:1.35 finally acts like it got method init() (and I think sends a reply,
         which dbus isn't configured to let dbus-monitor see)
:1.17 sends version to ServiceName

Note that if ServiceName is already registered before :1.17 starts up,
there are no unusual delays.

Simplified profile (sorry, I didn't have the initial signal of
NameOwnerChanged for :1.35 in here)

mc	1253210449	162033	1	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	Hello
sig	1253210449	204469	10	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253210449	204727	2	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	RequestName
mc	1253210449	223718	52	:1.17	/com/foo/ServiceName	com.foo.ServiceName	init
mc	1253210449	250102	3	:1.35	/org/freedesktop/DBus	org.freedesktop.DBus	AddMatch
mc	1253210474	268186	53	:1.17	/com/foo/ServiceName	com.foo.ServiceName	version
mc	1253210475	397637	54	:1.17	/com/foo/ServiceName	com.foo.ServiceName	command

So, I assume the delay is a retry within dbus to deliver the message
before giving up.  Even if it's queued in dbus, why isn't it delivered
when :1.35 (ServiceName) does the AddMatch?

Also note: the previous owner of ServiceName had been killed, and
appropriate NameOwnerChanged had occurred.  From another run:

sig	1253221607	797520	17	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253221607	797769	11	:1.44	/org/freedesktop/DBus	org.freedesktop.DBus	ReleaseName
sig	1253221607	867286	18	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged

The first NameOwnerChanged is for com.foo.ServiceName, the second is for :1.44


-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...

Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

[Meier, A. <and...@sc...>]

In the past week I worked on the echo example and tried to figure out
why it did not work.

It occurred to me that the multi threading cannot work since libdbus
does a poll and dbus-cplusplus does a poll as well on the same file
descriptor which cannot be safe.

My echo-client blocked for 25 secs after a client issued a Hello
request. The server's response let the dispatcher return from the poll
call. The following watch_ready read the message from the socket but had
it not ready to dispatch before the client issued its blocking poll.
Then the response was ready but the client could not be woken up.

My first idea was that we must somehow be able to wake up the client,
then I realized that this code was located in libdbus. The second idea
was to have a separate connection for each server and client object.

To ensure that the dispatcher is not polling the client connections and
accidentally receive responses an additional dummy dispatcher must be
created and set as default_dispatcher while creating the client
connections.

Please have a look at my patch.
It fixed the echo example for me.

Best regards,
Andreas

> -----Original Message-----
> From: Andreas Volz [mailto:li...@br...]
> Sent: Dienstag, 14. Juli 2009 17:48
> To: dbu...@li...
> Subject: [sls][heur] Re: [dbus-cplusplus-devel] dbus-c++ echo sample
fails
> 
> Am Wed, 8 Jul 2009 11:04:50 -0700 schrieb Bruce, Henry:
> 
> Yes, the example is bad. If someone provides a better one I'll commit
> it.
> 
> regards
> Andreas
> 
> > Sorry - just realized that applications set the main loop type. So
> > echo sample still fails with Glib main loop. Maybe best just to
> > remove it from the source tree. A sample that doesn't work is a
> > barrier to adoption.
> >
> > The properties sample works just fine. Not sure why the client needs
> > to spawn a thread. Can someone explain?
> >
> > I've got a Visual Studio build with the Glib main loop and the
> > "properties" sample, but client / server comms are not working. Dbus
> > monitor sees the client request, but server doesn't pick it up. I'll
> > keep debugging.
> >
> > Henry
> >
> >
> > -----Original Message-----
> > From: Bruce, Henry [mailto:hen...@in...]
> > Sent: Tuesday, July 07, 2009 12:05 PM
> > To: dbu...@li...
> > Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails
> >
> > Thanks to all who replied to my email. I've been digging deeper and
> > have some questions and comments
> >
> > 1. Does "main loop integration" apply to client and server
> > applications and/or the binding library itself (i.e. dbus-c++
library)
> >
> > 2. I switched to echo client and server applications to use the Glib
> > main loop but still see the same "OOM" error on the client. As the
> > dispatch enter and leave method are stubbed out in the Glib
> > implementation, I created my own main loop in the client and server
> > applications.
> >
> > 3. Is it possible to change the main loop used by the binding? If
so,
> > are there instructions on how to do this ? I tried swapping out
> > eventloop.h and for glib-integration.h in dispatcher.h and changing
> > type of default_dispatcher accordingly, but got compiler errors
> > (couldn't find any of the "Internal" sub classes).
> >
> > 4. If I can work out how to do (3) for Glib, I can see a route to
> > Visual Studio port.
> >
> > Henry
> >
> >
> >
> > -----Original Message-----
> > From: Andreas Volz [mailto:li...@br...]
> > Sent: Thursday, July 02, 2009 12:45 PM
> > To: dbu...@li...
> > Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails
> >
> > Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry:
> >
> > Hello Henry,
> >
> > To be honest I know this comment, but never experienced this error.
> > And I use Dbus-C++ for a heavy communicating application.
> >
> > Which main loop integration do you use? Try the Ecore or Glib loop.
> > The default one is buggy.
> >
> > regards
> > Andreas
> >
> > > All,
> > >
> > > I have been evaluating dbus-c++. I really like the design - it
makes
> > > good use of C++ and is much easier to use the dbus-glib. I also
like
> > > the use of XML service description files. When I built and ran the
> > > "echo" sample, the client failed after a few requests with a "not
> > > enough memory" exception. When I looked at the source for
> > > echo-client.cpp I saw the comment "For some strange reason,
libdbus
> > > frequently dies with an OOM". Sure enough, it had.
> > >
> > > I'd really like to use dbus-c++, but it just doesn't seem stable
> > > enough. Has anyone root caused this behavior?
> > >
> > > Hoping that someone will save me from dbus-glib,
> > >
> > > Thanks,
> > >
> > > Henry Bruce
> > >
> > >
> > >
> > >
------------------------------------------------------------------------
------
> > > _______________________________________________
> > > dbus-cplusplus-devel mailing list
> > > dbu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> > >
> >
> >
------------------------------------------------------------------------
------
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >
> >
------------------------------------------------------------------------
------
> > Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a limited
> > time, vendors submitting new applications to BlackBerry App
World(TM)
> > will have the opportunity to enter the BlackBerry Developer
> > Challenge. See full prize details at: http://p.sf.net/sfu/blackberry
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >
------------------------------------------------------------------------
------
> > Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a limited
> > time, vendors submitting new applications to BlackBerry App
World(TM)
> > will have the opportunity to enter the BlackBerry Developer
> > Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >
> 
>
------------------------------------------------------------------------
------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited
time,
> vendors submitting new applications to BlackBerry App World(TM) will
have
> the opportunity to enter the BlackBerry Developer Challenge. See full
prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

Re: [dbus-cplusplus-devel] Problem with the DBus::MessageIter::operator>>( DBus::MessageIter & iter, DBus::Variant & val )

[Andreas V. <li...@br...>]

Am Tue, 6 Oct 2009 23:19:38 -0400 schrieb asdfffdsa:

Hello (what ever your name is),

is the source from the fdo.org GIT repository or that from
gitorious.org? I ask because the generator is different.

Could you send me a minimal example with Makefile, XML and source that
compiles? Then I try it on my system.

To be honest I didn't work much with Variant in the past. So I don't
see the problem from only looking on your source. I've to try it.

regards
	Andreas

> Hello, I am new to dbus-c++.  I am very enthusiastic about this
> project (and the dbus and hal projects).  I've installed dbus-c++
> from the Archlinux User Repository ( dbus-c++ 20090929-1 ).  I will
> be downloading the source over night to further inspect the problem
> (my ISP has a very strict usage policy).
> 
> I seem to be having a problem with the DBus::MessageIter::operator>>(
> DBus::MessageIter & iter, DBus::Variant & val ) function
> ( declaration is in types.h ).  I've used the "dbusxx-xml2cpp" binary
> to generate proxy pattern classes.
> 
> *Here is my code:*
> // halDeviceProxy is a variable of a dbusxx-xml2cpp-generated proxy
> class for the "org.freedesktop.Hal.device" interface
> ::DBus::Variant variant = halDeviceProxy.GetProperty(
> std::string(propertyName) );
> 
> 
> *Here is the dbusxx-xml2cpp-generated proxy code:*
> ::DBus::Variant GetProperty(const std::string& key)
> {
>         ::DBus::CallMessage call;
>         ::DBus::MessageIter wi = call.writer();
>         wi << key;
>         call.member("GetProperty");
>         ::DBus::Message ret = invoke_method(call);
>         ::DBus::MessageIter ri = ret.reader();
> 
>         ::DBus::Variant argout;
>         ri >> argout;  *// this line causes an exception to be thrown*
>         return argout;
> }
> 
> 
> *The "ri >> argout" call is causing the following error/exception:*
> terminate called after throwing an instance of
> 'DBus::ErrorInvalidArgs' what():  variant type expected
> Aborted
> 
> 
> Naturally, "ri >> argout" is passing in a variant type, so I'm not
> sure what the problem is.  The odd thing about this is that functions
> such as GetAllProperties() work fine (which returns a
> std::map<std::string,DBus::Variant>).
> 
> I will be looking over the source when I get a chance, but if anyone
> has any ideas in the mean time, it would be very helpful.