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

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

[Bruce, H. <hen...@in...>]

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

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

[Mat <mat...@gm...>]

Hi Henry Bruce,

I encountered the same problem, too.

=== execute result ===
terminate called after throwing an instance of 'DBus::Error'
  what():  Not enough memory
Aborted
==================

When I execute more times, it could connect successfully, and when I use
other dbus-client to send request, like "d-feet" and "dbus-send", it works
fine.
So I guess the problem may caused by the client implementation.


=== machine ===
Linux localhost 2.6.30-gentoo-r1 #3 SMP Sun Jul 5 22:09:23 CST 2009 i686
Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux
gcc version 4.3.2
==============

=== top ===
 4813 mat       20   0  132m 1584 1268 S    0  0.1   0:00.01
lt-echo-client-
==========

Hope this helps,

sincerely, Mat.


On Fri, Jul 3, 2009 at 4:25 AM, Bruce, Henry <hen...@in...> wrote:

> Andreas,
>
> Thanks for the reply.
>
> It looks like I used the default main loop. I'll look into swapping for the
> glib main loop. I guess the glib sample shows me how to do this ?
>
> This is encouraging news, as I also have to support Visual Studio builds
> (using WinDBus) and my initial port didn't go well, but it may have been the
> other main loop options that caused the problems.
>
> FYI dbus-glib Visual Studio port went smoothly and is running fine, so I'm
> tempted to go with the "bird in the hand" option.
>
> I'll do some digging and get back to you.
>
> 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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>

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

[Bruce, H. <hen...@in...>]

Andreas,

Thanks for the reply.

It looks like I used the default main loop. I'll look into swapping for the glib main loop. I guess the glib sample shows me how to do this ?

This is encouraging news, as I also have to support Visual Studio builds (using WinDBus) and my initial port didn't go well, but it may have been the other main loop options that caused the problems.

FYI dbus-glib Visual Studio port went smoothly and is running fine, so I'm tempted to go with the "bird in the hand" option.

I'll do some digging and get back to you.

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

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

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

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] dbus-c++ echo sample fails

[Bruce, H. <hen...@in...>]

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

Re: [dbus-cplusplus-devel] D-Bus C++ on windows?

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

Am Wed, 24 Jun 2009 14:10:48 +0800 schrieb Mat:

Hello Mat,

I'm happy that DBus-C++ is useful for your application.

I assume it would simply compile on win32 as long as Dbus itself is
available.

Some time ago I used MinGW to compile a autotools based application.
Currently I would only develop on Windows for money. It's bad to waste
my spare time with windows. :-)

But if you've some errors related to Dbus-C++ while compiling with
windows that ask here. Maybe someone could help you.

regards
Andreas

> Hello everyone,
> 
> I'm writing a program[1] which use D-Bus C++ as IPC library.
> It works quite good on Linux.-- Thanks to all developer's great
> effort to D-Bus C++. --
> 
> I wish to port the program from linux to wndows which depends on
> D-Bus C++, however I don't know how to use/port D-Bus C++ on win32
> platform. Could someone help me , or  give me some hints or
> suggestions to solve this problem?
> 
> sincerely, Mat.
> 
> [1]. http://code.google.com/p/inkboardng/

[dbus-cplusplus-devel] D-Bus C++ on windows?

[Mat <mat...@gm...>]

Hello everyone,

I'm writing a program[1] which use D-Bus C++ as IPC library.
It works quite good on Linux.-- Thanks to all developer's great effort to
D-Bus C++. --

I wish to port the program from linux to wndows which depends on D-Bus C++,
  however I don't know how to use/port D-Bus C++ on win32 platform.
Could someone help me , or  give me some hints or suggestions to solve this
problem?

sincerely, Mat.

[1]. http://code.google.com/p/inkboardng/

Re: [dbus-cplusplus-devel] Setting the callback function and data in dbus-c++ for async calls

[David K. <zu...@li...>]

Hello Jay,

you might have a look in the archives for:

Date: Tue, 31 Mar 2009 18:10:14 -0400
From: Schmottlach, Glenn
Subject: [dbus-cplusplus-devel] FYI: Asynchronous support for client / 
servers

Best regards,

David


On Tue, 9 Jun 2009, Freyensee, James P wrote:

> Date: Tue, 9 Jun 2009 16:11:54 -0700
> From: "Freyensee, James P" <jam...@in...>
> To: "dbu...@li..."
>     <dbu...@li...>
> Cc: "Ahmed, Suhail" <suh...@in...>,
>     "Benis, Robertino" <rob...@in...>
> Subject: [dbus-cplusplus-devel] Setting the callback function and data in
>     dbus-c++ for async calls
> 
> Hello:
>
> I am struggling to understand how I could do an asynchronous call using dbus-c++ and was wondering if anyone has any currently working example code, explanation, or a tutorial to help me out.
>
> This is what I know (I believe at least).
>
> For asynchronous calls I need to call the dbus function
>
> dbus_bool_t  dbus_pending_call_set_notify ( DBusPendingCall *  pending, DBusPendingCallNotifyFunction  function, void *  user_data, DBusFreeFunction  free_user_data  )
>
> This happens when the constructor
>
> PendingCall::PendingCall(PendingCall::Private *p) : _pvt(p) {}
>
> is called.
>
> I believe this PendingCall::PendingCall() constructor called when the function in Connection.cpp:
>
> PendingCall Connection::send_async(Message &msg, int timeout)
>
> is called.
>
> Now I was thinking that a new, unwritten function in object.cpp needs be written as follows that would call send_async():
>
> PendingCall ObjectProxy::_invoke_method_async(CallMessage &call)
> {
> 	if (call.path() == NULL)
> 		call.path(path().c_str());
>
> 	if (call.destination() == NULL)
> 		call.destination(service().c_str());
>
> 	return conn().send_async(call);
> }
>
> This is actually pretty similar to
>
> Message ObjectProxy::_invoke_method(CallMessage &call) {}
>
> in Object.cpp.
>
> The big question is how do I use this dbus-c++ framework to set the (DBusPendingCallNotifyFunction  function, void *  user_data) parameters of the dbus_pending_call_set_notify() function?  I figure I need to set some parameters in the CallMessage object in ObjectProxy::_invoke_method_async() and/or the Message object in the Connection::send_async().  However, I don't know what to do and how to do it.
>
> Second question- is there anything else I am missing that I would need to do to make the callback operation work right in this dbus-c++ framework?
>
> Thank you for the help!
>
> Regards,
> Jay Freyensee
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>

Re: [dbus-cplusplus-devel] Setting the callback function and data in dbus-c++ for async calls

[Schmottlach, G. <gle...@ha...>]

It may be better for you to exam this fork of the D-Bus C++ binding where both asynchronous client/server mechanisms are supported:

git://zub.lamer.la/dbus-c++-async.git

I don't believe the "original" C++ binding really supported this.

Also, don't use the C++ binding from different threads because the underlying library (D-Bus Lib) really isn't thread-safe when making asynchronous requests. (See: http://lists.freedesktop.org/archives/dbus/2009-March/011031.html) for more details). It exhibits several race conditions.

The example programs in the above GIT repository are pretty much broken. They compile but won't work so don't use them as a guide. The underlying binding there, however, will work in the asynchronous fashion you desire.

Good luck . . .


-----Original Message-----
From: Freyensee, James P [mailto:jam...@in...] 
Sent: Tuesday, June 09, 2009 7:12 PM
To: dbu...@li...
Cc: Ahmed, Suhail; Benis, Robertino
Subject: [dbus-cplusplus-devel] Setting the callback function and data in dbus-c++ for async calls

Hello:

I am struggling to understand how I could do an asynchronous call using dbus-c++ and was wondering if anyone has any currently working example code, explanation, or a tutorial to help me out.

This is what I know (I believe at least).

For asynchronous calls I need to call the dbus function 

dbus_bool_t  dbus_pending_call_set_notify ( DBusPendingCall *  pending, DBusPendingCallNotifyFunction  function, void *  user_data, DBusFreeFunction  free_user_data  )

This happens when the constructor 

PendingCall::PendingCall(PendingCall::Private *p) : _pvt(p) {}

is called.  

I believe this PendingCall::PendingCall() constructor called when the function in Connection.cpp:

PendingCall Connection::send_async(Message &msg, int timeout)

is called.  

Now I was thinking that a new, unwritten function in object.cpp needs be written as follows that would call send_async():

PendingCall ObjectProxy::_invoke_method_async(CallMessage &call)
{
	if (call.path() == NULL)
		call.path(path().c_str());

	if (call.destination() == NULL)
		call.destination(service().c_str());

	return conn().send_async(call);
}

This is actually pretty similar to 

Message ObjectProxy::_invoke_method(CallMessage &call) {}

in Object.cpp.

The big question is how do I use this dbus-c++ framework to set the (DBusPendingCallNotifyFunction  function, void *  user_data) parameters of the dbus_pending_call_set_notify() function?  I figure I need to set some parameters in the CallMessage object in ObjectProxy::_invoke_method_async() and/or the Message object in the Connection::send_async().  However, I don't know what to do and how to do it.

Second question- is there anything else I am missing that I would need to do to make the callback operation work right in this dbus-c++ framework?

Thank you for the help!

Regards,
Jay Freyensee


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

[dbus-cplusplus-devel] Setting the callback function and data in dbus-c++ for async calls

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

Hello:

I am struggling to understand how I could do an asynchronous call using dbus-c++ and was wondering if anyone has any currently working example code, explanation, or a tutorial to help me out.

This is what I know (I believe at least).

For asynchronous calls I need to call the dbus function 

dbus_bool_t  dbus_pending_call_set_notify ( DBusPendingCall *  pending, DBusPendingCallNotifyFunction  function, void *  user_data, DBusFreeFunction  free_user_data  )

This happens when the constructor 

PendingCall::PendingCall(PendingCall::Private *p) : _pvt(p) {}

is called.  

I believe this PendingCall::PendingCall() constructor called when the function in Connection.cpp:

PendingCall Connection::send_async(Message &msg, int timeout)

is called.  

Now I was thinking that a new, unwritten function in object.cpp needs be written as follows that would call send_async():

PendingCall ObjectProxy::_invoke_method_async(CallMessage &call)
{
	if (call.path() == NULL)
		call.path(path().c_str());

	if (call.destination() == NULL)
		call.destination(service().c_str());

	return conn().send_async(call);
}

This is actually pretty similar to 

Message ObjectProxy::_invoke_method(CallMessage &call) {}

in Object.cpp.

The big question is how do I use this dbus-c++ framework to set the (DBusPendingCallNotifyFunction  function, void *  user_data) parameters of the dbus_pending_call_set_notify() function?  I figure I need to set some parameters in the CallMessage object in ObjectProxy::_invoke_method_async() and/or the Message object in the Connection::send_async().  However, I don't know what to do and how to do it.

Second question- is there anything else I am missing that I would need to do to make the callback operation work right in this dbus-c++ framework?

Thank you for the help!

Regards,
Jay Freyensee

Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several simple array.

[Redouane S. <red...@fr...>]

Hi,

I am about to merge again with the latest version
(git://anongit.freedesktop.org/git/dbus/dbus-c++/)

If I create a bug and a patch for each feature or bug, will it be possible
ton integrate them in the git repository ?

Regards,

Redouane.




-----Original Message-----
From: Andreas Volz [mailto:li...@br...] 
Sent: Tuesday, March 31, 2009 8:07 PM
To: dbu...@li...
Subject: Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several
simple array.

Am Thu, 26 Feb 2009 19:20:11 +0100 schrieb Redouane SOUM:

Hello Redouane,

not really. Currently my task is to better organize the xml2cpp parser
and then in the next step merge the one one gitorious and on fd.org.
Maybe you've seen my last commits in both branches. So your patch
won't apply to the current fd.org sources. I would suggest to do it in
smaller steps:

1. Split your bugfixes and features (one bug for each)

2. We try to integrate your library changes

3. I'm writing some unit tests to ensure that modifying the generator
doesn't destroy any yet working features.

4. Then as last step we could accept patches for xml2cpp. I think
after reworking the generator your changes are easier to understand and
review. The generator functions are really big and not that easy to
understand currently. It took me many time to get deeper into it.

regards
Andreas

> Hi,
> 
> Did you have time to check the patch ?
> 
> Regards.
> 
> -----Original Message-----
> From: Andreas Volz [mailto:li...@br...] 
> Sent: Tuesday, February 10, 2009 7:17 PM
> To: dbu...@li...
> Subject: Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including
> several simple array.
> 
> Am Wed, 21 Jan 2009 17:41:50 +0100 schrieb Redouane SOUM:
> 
> Hello Redouane,
> 
> sorry for not answering your mail. I'll try it in the next days. The
> problem is that in I work mainly on base of the gitorious branch. The
> generator there differs much from the fdo one. So I think it doesn't
> apply on my modified generator. But I think it has this bug also.
> 
> I search for a way to combine the source of both so that I only have
> to work on one source.
> 
> I've not yet tried your patch, but will do in the next days.
> 
> A good idea for the future would be a set of generator unit tests.
> Then one could apply patches and after passing all unit test it could
> be applied. Currently I've to test or review that patch. Because if I
> apply it with my account I've to "guarantee" for it's correctness.
> 
> regards
> Andreas
> 
> > If we use complex structure that include simple array, the type
> > isn't generated properly.
> > Exemple : (iiiua(ayayayiiiii))
> >  
> > Generated type (with current version of xml2cpp):
> >  
> > ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> > std::vector< ::DBus::Struct< std::vector< uint8_t, std::vector<
> > uint8_t, std::vector< uint8_t, int32_t, int32_t, int32_t, int32_t,
> > int32_t > > > >,
> > >
> > >, & evt
> >  
> >  
> > Type expected:
> >  
> >  ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> > std::vector< ::DBus::Struct< std::vector< uint8_t >, std::vector<
> > uint8_t >, std::vector< uint8_t >, int32_t, int32_t, int32_t,
> > int32_t, int32_t > > > evt;
> >  
> >  
> >  
> > I would like to submit a patch fixing this problem and adding some
> > features:
> > 
> >  
> >  
> > Xml2cpp
> >         Bug fix:
> >              Problem in type generation with complex array
> >  
> >         Feature:
> >             Add nonblock function for each method in the proxy
> > generation 
> > Dispatcher/connection
> >  
> >         Feature:
> >             Add constructor to create a connection passing a
> > dispatcher (instead of creating a connection with default dispatcher
> > and use setup after)
> >             Add fd to allow dispatcher to leave directly when leave
> > method is called (instead of waiting for the timeout on the select)
> >  
> > Red1
> > 
> >  
> > 
> >  
> > 
> > Ps : see bug https://bugs.freedesktop.org/show_bug.cgi?id=19518
> > 
> >  
> > 
> 
>
----------------------------------------------------------------------------
> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
> of local
> resources and data with the reach of the web. Download the Adobe AIR
> SDK and Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________ 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

Re: [dbus-cplusplus-devel] D-Bus C++

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

Am Tue, 26 May 2009 14:21:35 +0200 schrieb Meier, Andreas:

Hello Andreas,

I created the version with Ecore integration in the gitorious branch.
So if you've problems report them here. I would like to get more
feedback about it. If it works for several persons I'll integrate it
into the main branch on fd.org.

It's not much work to change the Echo example to Ecore main loop.

It works the same way as the glib dispatcher.

But take caution with the threads in the example. Also the Ecore
binding is not thread safe! But as long as you call a Dbus-C++ function
from within a Ecore loop callback there will be no problems.

regards
Andreas

> Hello Andreas
> 
> Thank you for your quick answer.
> 
> Fixing the dbus-C++ main-loop was my first idea. Then I learnt of the
> existence of the dbus-cplusplus bindings with integrated ecore main
> loop. In the meantime I was having a look at that package...
> 
> But after patching the echo example client based on the ecore example
> (exchanging DBus::BusDispatcher with DBus::Ecore::BusDispatcher
> and introducing ecore main loop handling) it is still failing.
> Or is it more complicated to rewrite the echo example to work with the
> ecore main loop?
> 
> > ...
> > I also played around with the echo example and had various threading
> > problems. As long as you use the own main loop dispatcher you'll get
> > those problem. You should use the glib or ecore integration to get
> > it working.
> >
> > I've some ideas to get the Dbus-C++ main loop working also with
> > threads. But you're right the echo example is broken currently.
> > Don't use it currently or change it to use glib and provide a patch.
> > ...
> 
> You stated that one should use glib or ecore integration and a
> sentence further down you mention glib only. Is the glib integration
> better tested
> than the ecore one? The ecore integration is more appealing to me
> since its memory footprint is much smaller.
> 
> What do you think is more promising with a limited time budget? Fixing
> multi-threading issue of dbus-C++ or debugging dbus-cplusplus with
> ecore integration?
> 
> Have a good day,
> Andreas
> 

Re: [dbus-cplusplus-devel] D-Bus C++

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

Am Mon, 18 May 2009 15:22:24 +0200 schrieb Meier, Andreas:

> Hello,
> 
> > ...
> > I also played around with the echo example and had various threading
> > problems. As long as you use the own main loop dispatcher you'll get
> > those problem. You should use the glib or ecore integration to get
> > it working.
> > 
> > I've some ideas to get the Dbus-C++ main loop working also with
> > threads. But you're right the echo example is broken currently.
> > Don't use it currently or change it to use glib and provide a patch.
> 
> In the end I would like to have a client-side application with a main
> loop
> and various threads from where blocking method calls are invoked.
> 
> I started with the echo-example and found it broken.
> 
> I would be glad if you could describe your previously mentioned ideas
> in short terms? So I have a better understanding of where to start
> looking for the problem.

Hello Andreas,

The problem is to get a hook from the event loop where it's save to
queue new requests in dbus-c++. In the Glib and Ecore there's a real
event loop. So I would do it in dispatcher.cpp:

void BusDispatcher::enter()
{
	debug_log("entering dispatcher %p", this);

	_running = true;

	while (_running)
	{
		// -> call the callback here!
		do_iteration();
	}

	debug_log("leaving dispatcher %p", this);
}

The while loop there is our main event loop. So as long as Dbus-C++
isn't complete thread save it's only save to queue new requests outside
the do_iteration() function. So far the theory... :-)

I would add a function callback to the prototype of enter(). Then in
the loop before the do_iteration() I would call that callback function.

Then in the e.g. echo example you've this callback function from where
it's save to call Dbus-C++ functions. So here is a snippet from the
echo client:

void *greeter_thread(void *arg)
{
	DBus::Connection *conn = reinterpret_cast<DBus::Connection
*>(arg);

	EchoClient client(*conn, ECHO_SERVER_PATH, ECHO_SERVER_NAME);

	char idstr[16];
	string s ("TestString");
	
	snprintf(idstr, sizeof(idstr), "%lu", pthread_self());

	for (int i = 0; i < 1000 && spin; ++i)
	{
		cout << client.Echo(s) << endl;
	}
	
	cout << idstr << " done " << endl;

	return NULL;
}

I would create a queue protected by a mutex and queue requests from the
thread and work on this queue in the callback function. So it's sure to
call a Dbus-C++ function.

I would try it this way. But sorry I'm busy with another project. But
if you had success I'll commit your patches into both branches.

regards
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++

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

Hello,

> ...
> I also played around with the echo example and had various threading
> problems. As long as you use the own main loop dispatcher you'll get
> those problem. You should use the glib or ecore integration to get it
> working.
> 
> I've some ideas to get the Dbus-C++ main loop working also with
> threads. But you're right the echo example is broken currently. Don't
> use it currently or change it to use glib and provide a patch.

In the end I would like to have a client-side application with a main
loop
and various threads from where blocking method calls are invoked.

I started with the echo-example and found it broken.

I would be glad if you could describe your previously mentioned ideas in
short terms? So I have a better understanding of where to start looking
for the problem.

Best regards,
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++ dbusxx-xml2cpp compiler

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

Am Wed, 22 Apr 2009 13:33:50 -0400 schrieb Schmottlach, Glenn:

> Hi Markus -
> 
> If I recall this bug was fixed in the "unofficial" variant:
> 
> git clone git://gitorious.org/dbus-cplusplus/mainline.git
> 
> Also, there exists another branch here that doesn't exhibit this bug
> either:
> 
> git://zub.lamer.la/dbus-c++-async.git
> 
> As you can see the D-Bus C++ binding has more or less forked into
> three branches. The "official" branch (as stated in the D-Bus
> bindings page) is probably the oldest and suffering the most from
> bit-rot.

I'm not sure if it's fixed int the gitorious branch. Please try it and
report on the Dbus-C++ list. I won't fix any generator bugs in the
official version.

I try to merge all library changes back to the official library. But
the generator has changed to much. My next step is to harmonize the
generator.

regards
Andreas

Re: [dbus-cplusplus-devel] How to get the sender of a message inside the implementation of an Adaptor.

[Redouane S. <red...@fr...>]

Hi,

 

Ok i have the following stub (adaptor) generated from introspect :

 

    ::DBus::Message __my_func_stub(const ::DBus::CallMessage &call)

    {

        ::DBus::MessageIter ri = call.reader();

        int32_t argout1 = _my_func();

        ::DBus::ReturnMessage reply(call);

        ::DBus::MessageIter wi = reply.writer();

        wi << argout1;

        return reply;

    }

 

And I have to implement the function : 

 

int32_t MyClass::_my_func(  ){

      ..

}

 

 

I would like to get some information about the caller (connection id, pid,
uid) inside the implementation of _my_func().

 

Regards.

 

-----Original Message-----
From: Andreas Volz [mailto:li...@br...] 
Sent: Thursday, April 23, 2009 9:52 PM
To: dbu...@li...
Subject: Re: [dbus-cplusplus-devel] How to get the sender of a message
inside the implementation of an Adaptor.

 

Am Thu, 23 Apr 2009 17:27:34 +0200 schrieb Redouane SOUM:

 

> Hi,

> 

>  

> 

> Is it possible to get the sender of a message inside the

> implementation of an Adaptor ?

> 

>  

> 

> I think this could be done thanks to Message ::sender() , which is

> based on dbus_message_get_sender , but it seems this is only used in

> generated code.

 

Hello Redouane,

 

I'm not sure if I understood you complete. Could you show some code?

 

regards

Andreas

 

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

Crystal Reports &#45; New Free Runtime and 30 Day Trial

Check out the new simplified licensign option that enables unlimited

royalty&#45;free distribution of the report engine for externally facing 

server and web deployment.

http://p.sf.net/sfu/businessobjects

_______________________________________________

dbus-cplusplus-devel mailing list

dbu...@li...

https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

Re: [dbus-cplusplus-devel] How to get the sender of a message inside the implementation of an Adaptor.

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

Am Thu, 23 Apr 2009 17:27:34 +0200 schrieb Redouane SOUM:

> Hi,
> 
>  
> 
> Is it possible to get the sender of a message inside the
> implementation of an Adaptor ?
> 
>  
> 
> I think this could be done thanks to Message ::sender() , which is
> based on dbus_message_get_sender , but it seems this is only used in
> generated code.

Hello Redouane,

I'm not sure if I understood you complete. Could you show some code?

regards
Andreas

Re: [dbus-cplusplus-devel] DBus-C++ on_get_property

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

Am Wed, 22 Apr 2009 11:26:26 +0100 schrieb Markus Kohler:

> I found in properties.h the following code:
> 
> Message PropertiesAdaptor::Get(const CallMessage &call)
> {
>         [...]
>         Variant *value = interface->get_property(property_name);
> 
>         if (!value)
>                 throw ErrorFailed("requested property not found");
> 
>         on_get_property(*interface, property_name, *value);
> 
>         ReturnMessage reply(call);
> 
>         MessageIter wi = reply.writer();
> 
>         wi << *value;
>         return reply;
> }
> 
> If you make changes to value inside of on_get_property(...) it will
> be also written into the interface->get_property(property_name), i.e.
> changes in there will change the interface. Is this intended to be
> like this. I would have expected that inside on_get_property(...) you
> get the value that you can modify for the output to the client
> application only without changing the values in the interface. If the
> intention is the later the code should be:
> 
> Message PropertiesAdaptor::Get(const CallMessage &call)
> {
>         [...]
> -->    Variant value = *interface->get_property(property_name);
> 
>         if (!value)
>                 throw ErrorFailed("requested property not found");
> 
> -->    on_get_property(*interface, property_name, value);
> 
>         ReturnMessage reply(call);
> 
>         MessageIter wi = reply.writer();
> 
> -->    wi << value;
>         return reply;
> }
> 
> Comments?

Hello Markus,

currently I don't use properties, so I don't know it without deeper
investigation in this topic. To be honest I never used the "Variant"
type in my application. So as long that nobody writes unit tests I
couldn't check in the change.

I started to write some unit tests, but didn't yet commit it as I'm
again busy with another opensource project.

But if you create a bug report for it someone (I?) will have a look
later,

regards
Andreas

Re: [dbus-cplusplus-devel] D-Bus C++

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

Am Tue, 10 Mar 2009 14:40:18 +0000 schrieb Markus Kohler:

> Hello Paolo and Andreas,
> 
> besides two other bugs, I found a new one recently and tried to track
> it down. I am not sure whether it is a bug in D-Bus-C++ or (more
> likely) in libdbus. It looks like a deadlock. Constellation is the
> following:
> 
> Given:
> - application APP that implements the adaptor for interface A, the
> proxy for interface B (with methods and signals) and uses class C
> (standard C++ class)
> - B has, let's say, a method Create and a signal Created, i.e. in B's
> adaptor Create will call this-> Created to emit the signal
> - adaptor class of interface A uses method Create from interface B's
> proxy and method M from class C
> - class C implements interface B's proxy (to get notified about
> changes), i.e. implements callback function Created for interface B
> - class C's method M calls another methods of interface B's proxy
> (not Create)
> 
> This constellation makes application APP hang. Because of the
> "circular" arrangement it may be a deadlock but I could not find out
> more at this moment in time.
> 
> If I disable in adaptor of interface B "this->Created" call
> everything works fine.
> 
> Right now I think of separating the interface of B into two
> interfaces one with signals and one with methods which may help.

This is what I do for my application.

> Do you have a Bugtracker up where you collect this type of
> information? I looked at your official DBus page
> http://freedesktop.org/wiki/Software/dbus-c%2B%2B which points to
> Bugzilla. However there I could not find any activity on dbus-c++
> (only dbus c-lib).

Use this one:

http://sourceforge.net/tracker/?group_id=236997&atid=1101682

But please mark the "Group" which branch it is.

> Best regards,
> Markus
> 
> ps. the echo example of the newest d-bus-c++ that I pulled from git
> still does not work: if you compile and use the echo-client it
> behaves random in the way that it outputs sometimes all Hello echos,
> sometimes only the onces from the first thread and so on. I believe
> it has to do with Bug 857 at
> http://bugs.freedesktop.org/attachment.cgi?id=22759&action=edit where
> it says: "We're not currently threadsafe, and the documentation
> should really reflect that.  Even better would be to fix it of
> course."

I also played around with the echo example and had various threading
problems. As long as you use the own main loop dispatcher you'll get
those problem. You should use the glib or ecore integration to get it
working.

I've some ideas to get the Dbus-C++ main loop working also with
threads. But you're right the echo example is broken currently. Don't
use it currently or change it to use glib and provide a patch.

regards
Andreas

[dbus-cplusplus-devel] How to get the sender of a message inside the implementation of an Adaptor.

[Redouane S. <red...@fr...>]

Hi,

 

Is it possible to get the sender of a message inside the implementation of
an Adaptor ?

 

I think this could be done thanks to Message ::sender() , which is based on
dbus_message_get_sender , but it seems this is only used in generated code.

 

Regards

[dbus-cplusplus-devel] FYI: Asynchronous support for client / servers

[Schmottlach, G. <gle...@ha...>]

Hi All -

 

I'd like to announce the general availability of (yet another) fork of
the D-Bus C++ binding that supports the implementation (and generation)
of asynchronous clients and services. This majority of the
implementation was developed by Paolo Durante (the original maintainer)
to extend the previous synchronous-only services to support the
asynchronous features of D-Bus.  Along the way I fixed some bugs, ported
the code generator to Windows, and generally attempted to "harden" the
implementation.

 

David Kozub was kind of enough to offer to post the code here and made
sure it runs under Linux (the extensions were originally developed under
QNX):

 

 git://zub.lamer.la/dbus-c++-async.git

 

Please note, I cannot offer much in the way of documentation at this
point with regard to the port. There are a couple of new annotations in
the XML services file that enables the async features in the code
generator. Please see the code for more details. Also, the binding, in
general, is a little shakey with regards to threading. This isn't so
much the fault of the binding but underlying issues in the D-Bus library
itself. These issues become more pronounced when using the asynchronous
features of the binding. In general, I recommend accessing the binding
(and thus the D-Bus library) from only a single thread. Your mileage may
vary.

 

Unfortunately this branch has some significant differences from
Andreas's gitorious fork (sorry about that). As a result, I suspect it
won't be easy to integrate the changes into a single baseline. Is
anybody willing to take a stab it it? 

 

If you're interested in truly asynchronous clients and services then
this may be an option to consider. I'll try to answer any questions as
time permits.

 

Again, credit must be given to Paolo D. for the initial cut at async
support and David K. for doing the necessary legwork to post it on
publicly accessible GIT repository. I hope someone finds the code
useful.

 

Glenn

Re: [dbus-cplusplus-devel] Connection::request_name return value

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

Am Sat, 14 Mar 2009 18:25:46 +0300 schrieb Konishchev Dmitry:

> Please, say why dbus-c++ method
>        void Connection::request_name(const char *name, int flags)
> has void return type? The return value is very usable to prevent race
> conditions while requesting DBus name. Please, fix this method to
> return dbus_bus_request_name() value.

Hello Dmitry,

I looked into this topic and have seen this in the source:

void Connection::request_name(const char *name, int flags)
{
  ...
  //we deliberately don't check return value
  dbus_bus_request_name(_pvt->conn, name, flags, e);	
  ...
}

I've not written this code in Dbus-C++, so I don't understand the
meaning of that comment from the initial author.

For sure I could simply return the int from dbus_bus_request_name(),
but this would break the PImpl concept. This means it's at no place
needed to have <dbus/dbus.h> available for compiling a user application
of DBus-C++. So at least this has to be complete wrapped in some way.

And also the return value of '-1' has to be handled correct. I would
simply throw an Exception for this. But I'm not sure because of the
comment above...

@Paolo: Could you write some comments about this issue?

regards
Andreas

Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including several simple array.

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

Am Thu, 26 Feb 2009 19:20:11 +0100 schrieb Redouane SOUM:

Hello Redouane,

not really. Currently my task is to better organize the xml2cpp parser
and then in the next step merge the one one gitorious and on fd.org.
Maybe you've seen my last commits in both branches. So your patch
won't apply to the current fd.org sources. I would suggest to do it in
smaller steps:

1. Split your bugfixes and features (one bug for each)

2. We try to integrate your library changes

3. I'm writing some unit tests to ensure that modifying the generator
doesn't destroy any yet working features.

4. Then as last step we could accept patches for xml2cpp. I think
after reworking the generator your changes are easier to understand and
review. The generator functions are really big and not that easy to
understand currently. It took me many time to get deeper into it.

regards
Andreas

> Hi,
> 
> Did you have time to check the patch ?
> 
> Regards.
> 
> -----Original Message-----
> From: Andreas Volz [mailto:li...@br...] 
> Sent: Tuesday, February 10, 2009 7:17 PM
> To: dbu...@li...
> Subject: Re: [dbus-cplusplus-devel] Bug. xml2cpp structure including
> several simple array.
> 
> Am Wed, 21 Jan 2009 17:41:50 +0100 schrieb Redouane SOUM:
> 
> Hello Redouane,
> 
> sorry for not answering your mail. I'll try it in the next days. The
> problem is that in I work mainly on base of the gitorious branch. The
> generator there differs much from the fdo one. So I think it doesn't
> apply on my modified generator. But I think it has this bug also.
> 
> I search for a way to combine the source of both so that I only have
> to work on one source.
> 
> I've not yet tried your patch, but will do in the next days.
> 
> A good idea for the future would be a set of generator unit tests.
> Then one could apply patches and after passing all unit test it could
> be applied. Currently I've to test or review that patch. Because if I
> apply it with my account I've to "guarantee" for it's correctness.
> 
> regards
> Andreas
> 
> > If we use complex structure that include simple array, the type
> > isn't generated properly.
> > Exemple : (iiiua(ayayayiiiii))
> >  
> > Generated type (with current version of xml2cpp):
> >  
> > ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> > std::vector< ::DBus::Struct< std::vector< uint8_t, std::vector<
> > uint8_t, std::vector< uint8_t, int32_t, int32_t, int32_t, int32_t,
> > int32_t > > > >,
> > >
> > >, & evt
> >  
> >  
> > Type expected:
> >  
> >  ::DBus::Struct< int32_t, int32_t, int32_t, uint32_t,
> > std::vector< ::DBus::Struct< std::vector< uint8_t >, std::vector<
> > uint8_t >, std::vector< uint8_t >, int32_t, int32_t, int32_t,
> > int32_t, int32_t > > > evt;
> >  
> >  
> >  
> > I would like to submit a patch fixing this problem and adding some
> > features:
> > 
> >  
> >  
> > Xml2cpp
> >         Bug fix:
> >              Problem in type generation with complex array
> >  
> >         Feature:
> >             Add nonblock function for each method in the proxy
> > generation 
> > Dispatcher/connection
> >  
> >         Feature:
> >             Add constructor to create a connection passing a
> > dispatcher (instead of creating a connection with default dispatcher
> > and use setup after)
> >             Add fd to allow dispatcher to leave directly when leave
> > method is called (instead of waiting for the timeout on the select)
> >  
> > Red1
> > 
> >  
> > 
> >  
> > 
> > Ps : see bug https://bugs.freedesktop.org/show_bug.cgi?id=19518
> > 
> >  
> > 
> 
> ----------------------------------------------------------------------------
> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
> of local
> resources and data with the reach of the web. Download the Adobe AIR
> SDK and Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________ dbus-cplusplus-devel
> mailing list dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

Re: [dbus-cplusplus-devel] Asynchronous method call

[Schmottlach, G. <gle...@ha...>]

Hi -

We've already hacked up the C++ binding (with Paolo's initial help) to
support truly asynchronous calls along with a few other nice features.
I'm not sure how far this has diverged from the current branch
maintained by Andreas but you may be interested in it. I don't have the
time right now to try to integrate this with what's currently available
but if you're interested, and can suggest a home for it, I can make this
source code available to the larger community.

Also note: Asynchronous calls in a threaded D-Bus environment is
generally unstable (actually a D-Bus issue - not the binding). The
modified code is only experimental at this point but I have been
successfully using it for the past few months. There are probably still
a few bugs lurking in the background but I *think* I've found the more
significant ones. 

 

-----Original Message-----
From: David Kozub [mailto:zu...@li...] 
Sent: Monday, March 30, 2009 5:21 PM
To: dbu...@li...
Subject: [dbus-cplusplus-devel] Asynchronous method call

Hi,

I'm wondering - to what extent does libdbus-c++ support async method 
calls?

In the sources, I see there's:

PendingCall Connection::send_async(Message &message, int timeout = -1)

which looks rather promising.

I still haven't caught up with dbus, but... if the plumbing (Connection,

PendingCall) is there and is working, all that's missing to be able to 
easily use these from an interface proxy is to add:

InterfaceProxy::invoke_method_async()

analogous to InterfaceProxy::invoke_method(), and similar to 
ObjectProxy().

Is that all on crack? :)

Actually, I just hacked this in in my local sources... I'll c what 
happens.

Best regards,

David
zu...@li...


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

[dbus-cplusplus-devel] Asynchronous method call

[David K. <zu...@li...>]

Hi,

I'm wondering - to what extent does libdbus-c++ support async method 
calls?

In the sources, I see there's:

PendingCall Connection::send_async(Message &message, int timeout = -1)

which looks rather promising.

I still haven't caught up with dbus, but... if the plumbing (Connection, 
PendingCall) is there and is working, all that's missing to be able to 
easily use these from an interface proxy is to add:

InterfaceProxy::invoke_method_async()

analogous to InterfaceProxy::invoke_method(), and similar to 
ObjectProxy().

Is that all on crack? :)

Actually, I just hacked this in in my local sources... I'll c what 
happens.

Best regards,

David
zu...@li...