dbus-cxx-users Mailing List for dbus-cxx
Status: Beta
Brought to you by:
rvinyard
Menu
▾
▴
dbus-cxx-users — For those using the dbus-cxx library in their applications
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(11) |
Jul
(3) |
Aug
(1) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2012 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: Robert M. <rmi...@sy...> - 2014-12-23 17:21:00
|
The output from dbus-monitor does look correct. It's also possible that g++ is be a little too helpful and optimizing some of the values out. I ran a quick test just now, and I was able to get a bool value back. Here's a .tgz of the code that I used to test: http://rm5248.com/random/dbus-bool-test.tgz On Mon, Dec 22, 2014 at 1:29 PM, Fabrizio Lungo <fa...@lu...> wrote: > Okay, I ran dbus-monitor and all appears to be fine on the python end: > > method call sender=:1.1093 -> dest=com.ssokolow.QuickTile serial=2 path=/com/ssokolow/QuickTile; interface=com.ssokolow.QuickTile; member=doCommand > string "right" > method return sender=:1.1091 -> dest=:1.1093 reply_serial=2 > boolean false > > From what I can see the message is sent by my application correctly, the > python code successfully does what its meant to do (despite it returning > false - I am not actually sure of the conditions of the return as I am not > really interested in it for my code) and the response is sent back with the > right destination (based on the fact that was the source of the request) > with the same serial. > > I am no dbus expert but that output looks fine to me. > > Whilst searching for a solution I did find the threads regarding the hang > on void return types; I am not sure if this is the same or similar problem? > > Going to try and simplify my code just in-case my use of the return value > has caused some funky g++ compiler magic that results in the code breaking: > debugger is showing that bool _retval has been optimised out but that > could just be because it skips streaming retmsg >> _retval and just > returns _retval > > > > Many Thanks, > Fabrizio Lungo > > http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> > > On 22 December 2014 at 14:54, Robert Middleton <rmi...@sy...> > wrote: > >> There was a problem a long time ago with void methods not properly >> returning; this could be a similar problem. >> >> Could you run dbus-monitor at the same time and make sure that a >> method_reply is being sent back from the python application? >> >> On Mon, Dec 22, 2014 at 4:48 AM, Fabrizio Lungo <fa...@lu...> wrote: >> >>> I am not sure if this is a bug with dbus-cxx or if I am doing something >>> wrong. I am trying to use dbus-cxx to send a message to a dbus-python >>> application (quicktile). Using d-feet I can see that the signature is doCommand >>> (String command) |-> (Boolean arg_1). In cpp I have created a wrapper >>> class for the method: >>> >>> *quickTileProxy.h >>> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.h>* >>> >>> #define QT_DBUS_NAME "com.ssokolow.QuickTile"#define QT_OBJECT_PATH "/com/ssokolow/QuickTile"#define QT_INTERFACE "com.ssokolow.QuickTile" >>> class quickTileProxy { >>> DBus::ObjectProxy::pointer object;public: >>> DBus::MethodProxy<bool, std::string>& doCommand; >>> quickTileProxy(DBus::Connection::pointer connection);private: >>> >>> }; >>> >>> *quickTileProxy.cpp >>> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.cpp>* >>> >>> #include <dbus-cxx.h>#include "quickTileProxy.h" >>> >>> quickTileProxy::quickTileProxy(DBus::Connection::pointer connection) : >>> object(connection->create_object_proxy(QT_DBUS_NAME, QT_OBJECT_PATH)), >>> doCommand(*(object->create_method<bool,std::string>(QT_INTERFACE,"doCommand"))) >>> { >>> >>> } >>> >>> This is instantiated with: >>> >>> *opensnap.cpp:181 >>> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L181>* >>> >>> qt_proxy = new quickTileProxy(connection); >>> >>> and doCommand is called with the line: >>> >>> *opensnap.cpp:40 >>> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L40>* >>> >>> rtn = qt_proxy->doCommand(args); >>> >>> The command runs successfully on the quicktile daemon and the action is >>> performed however at this point the code hangs. Using gdb I have traced the >>> point that the code hangs to between lines 127 and 128 of >>> /usr/include/dbus-cxx-0.8/dbus-cxx/methodproxy.h: >>> >>> ReturnMessage::const_pointer retmsg = this->call( _callmsg ); >>> T_return _retval; >>> >>> The disassembly shows that it is in a __lll_lock_wait and would appear >>> to be deadlocked. The full disassembly: >>> >>> __lll_lock_wait() >>> __lll_lock_wait+28: mov %edx,%eax >>> __lll_lock_wait+30: xchg %eax,(%rdi) >>> __lll_lock_wait+32: test %eax,%eax >>> __lll_lock_wait+34: jne 0x7ffff2eb4115 <__lll_lock_wait+21> >>> __lll_lock_wait+36: pop %rdx >>> __lll_lock_wait+37: pop %r10 >>> __lll_lock_wait+39: retq >>> >>> I am currently using *aur/dbus-cxx 0.8.0-2* (which I think is the >>> latest) from the Arch Linux AUR. If you would like to browse or download >>> the full source code then it is available from Gitcdbs quilt >>> libglibmm-2.4-dev doxygen xsltprocHub >>> <https://github.com/flungo/opensnap-quicktile/tree/feature/dbus>. >>> Hopefully someone is able to shed some light on what is going wrong? >>> >>> I don’t *think* there is an issue with the python side of things as I >>> can execute fine with d-feet but the source for this is also available on >>> GitHub <https://github.com/ssokolow/quicktile>. >>> >>> Many Thanks, >>> Fabrizio Lungo >>> >>> http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Dbus-cxx-users mailing list >>> Dbu...@li... >>> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users >>> >>> >> >> |
|
From: Fabrizio L. <fa...@lu...> - 2014-12-22 18:30:46
|
Okay, I ran dbus-monitor and all appears to be fine on the python end: method call sender=:1.1093 -> dest=com.ssokolow.QuickTile serial=2 path=/com/ssokolow/QuickTile; interface=com.ssokolow.QuickTile; member=doCommand string "right" method return sender=:1.1091 -> dest=:1.1093 reply_serial=2 boolean false >From what I can see the message is sent by my application correctly, the python code successfully does what its meant to do (despite it returning false - I am not actually sure of the conditions of the return as I am not really interested in it for my code) and the response is sent back with the right destination (based on the fact that was the source of the request) with the same serial. I am no dbus expert but that output looks fine to me. Whilst searching for a solution I did find the threads regarding the hang on void return types; I am not sure if this is the same or similar problem? Going to try and simplify my code just in-case my use of the return value has caused some funky g++ compiler magic that results in the code breaking: debugger is showing that bool _retval has been optimised out but that could just be because it skips streaming retmsg >> _retval and just returns _retval Many Thanks, Fabrizio Lungo http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> On 22 December 2014 at 14:54, Robert Middleton <rmi...@sy...> wrote: > There was a problem a long time ago with void methods not properly > returning; this could be a similar problem. > > Could you run dbus-monitor at the same time and make sure that a > method_reply is being sent back from the python application? > > On Mon, Dec 22, 2014 at 4:48 AM, Fabrizio Lungo <fa...@lu...> wrote: > >> I am not sure if this is a bug with dbus-cxx or if I am doing something >> wrong. I am trying to use dbus-cxx to send a message to a dbus-python >> application (quicktile). Using d-feet I can see that the signature is doCommand >> (String command) |-> (Boolean arg_1). In cpp I have created a wrapper >> class for the method: >> >> *quickTileProxy.h >> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.h>* >> >> #define QT_DBUS_NAME "com.ssokolow.QuickTile"#define QT_OBJECT_PATH "/com/ssokolow/QuickTile"#define QT_INTERFACE "com.ssokolow.QuickTile" >> class quickTileProxy { >> DBus::ObjectProxy::pointer object;public: >> DBus::MethodProxy<bool, std::string>& doCommand; >> quickTileProxy(DBus::Connection::pointer connection);private: >> >> }; >> >> *quickTileProxy.cpp >> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.cpp>* >> >> #include <dbus-cxx.h>#include "quickTileProxy.h" >> >> quickTileProxy::quickTileProxy(DBus::Connection::pointer connection) : >> object(connection->create_object_proxy(QT_DBUS_NAME, QT_OBJECT_PATH)), >> doCommand(*(object->create_method<bool,std::string>(QT_INTERFACE,"doCommand"))) >> { >> >> } >> >> This is instantiated with: >> >> *opensnap.cpp:181 >> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L181>* >> >> qt_proxy = new quickTileProxy(connection); >> >> and doCommand is called with the line: >> >> *opensnap.cpp:40 >> <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L40>* >> >> rtn = qt_proxy->doCommand(args); >> >> The command runs successfully on the quicktile daemon and the action is >> performed however at this point the code hangs. Using gdb I have traced the >> point that the code hangs to between lines 127 and 128 of >> /usr/include/dbus-cxx-0.8/dbus-cxx/methodproxy.h: >> >> ReturnMessage::const_pointer retmsg = this->call( _callmsg ); >> T_return _retval; >> >> The disassembly shows that it is in a __lll_lock_wait and would appear >> to be deadlocked. The full disassembly: >> >> __lll_lock_wait() >> __lll_lock_wait+28: mov %edx,%eax >> __lll_lock_wait+30: xchg %eax,(%rdi) >> __lll_lock_wait+32: test %eax,%eax >> __lll_lock_wait+34: jne 0x7ffff2eb4115 <__lll_lock_wait+21> >> __lll_lock_wait+36: pop %rdx >> __lll_lock_wait+37: pop %r10 >> __lll_lock_wait+39: retq >> >> I am currently using *aur/dbus-cxx 0.8.0-2* (which I think is the >> latest) from the Arch Linux AUR. If you would like to browse or download >> the full source code then it is available from GitHub >> <https://github.com/flungo/opensnap-quicktile/tree/feature/dbus>. >> Hopefully someone is able to shed some light on what is going wrong? >> >> I don’t *think* there is an issue with the python side of things as I >> can execute fine with d-feet but the source for this is also available on >> GitHub <https://github.com/ssokolow/quicktile>. >> >> Many Thanks, >> Fabrizio Lungo >> >> http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> >> >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Dbus-cxx-users mailing list >> Dbu...@li... >> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users >> >> > > |
|
From: Robert M. <rmi...@sy...> - 2014-12-22 17:44:55
|
There was a problem a long time ago with void methods not properly returning; this could be a similar problem. Could you run dbus-monitor at the same time and make sure that a method_reply is being sent back from the python application? On Mon, Dec 22, 2014 at 4:48 AM, Fabrizio Lungo <fa...@lu...> wrote: > I am not sure if this is a bug with dbus-cxx or if I am doing something > wrong. I am trying to use dbus-cxx to send a message to a dbus-python > application (quicktile). Using d-feet I can see that the signature is doCommand > (String command) |-> (Boolean arg_1). In cpp I have created a wrapper > class for the method: > > *quickTileProxy.h > <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.h>* > > #define QT_DBUS_NAME "com.ssokolow.QuickTile"#define QT_OBJECT_PATH "/com/ssokolow/QuickTile"#define QT_INTERFACE "com.ssokolow.QuickTile" > class quickTileProxy { > DBus::ObjectProxy::pointer object;public: > DBus::MethodProxy<bool, std::string>& doCommand; > quickTileProxy(DBus::Connection::pointer connection);private: > > }; > > *quickTileProxy.cpp > <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.cpp>* > > #include <dbus-cxx.h>#include "quickTileProxy.h" > > quickTileProxy::quickTileProxy(DBus::Connection::pointer connection) : > object(connection->create_object_proxy(QT_DBUS_NAME, QT_OBJECT_PATH)), > doCommand(*(object->create_method<bool,std::string>(QT_INTERFACE,"doCommand"))) > { > > } > > This is instantiated with: > > *opensnap.cpp:181 > <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L181>* > > qt_proxy = new quickTileProxy(connection); > > and doCommand is called with the line: > > *opensnap.cpp:40 > <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L40>* > > rtn = qt_proxy->doCommand(args); > > The command runs successfully on the quicktile daemon and the action is > performed however at this point the code hangs. Using gdb I have traced the > point that the code hangs to between lines 127 and 128 of > /usr/include/dbus-cxx-0.8/dbus-cxx/methodproxy.h: > > ReturnMessage::const_pointer retmsg = this->call( _callmsg ); > T_return _retval; > > The disassembly shows that it is in a __lll_lock_wait and would appear to > be deadlocked. The full disassembly: > > __lll_lock_wait() > __lll_lock_wait+28: mov %edx,%eax > __lll_lock_wait+30: xchg %eax,(%rdi) > __lll_lock_wait+32: test %eax,%eax > __lll_lock_wait+34: jne 0x7ffff2eb4115 <__lll_lock_wait+21> > __lll_lock_wait+36: pop %rdx > __lll_lock_wait+37: pop %r10 > __lll_lock_wait+39: retq > > I am currently using *aur/dbus-cxx 0.8.0-2* (which I think is the latest) > from the Arch Linux AUR. If you would like to browse or download the full > source code then it is available from GitHub > <https://github.com/flungo/opensnap-quicktile/tree/feature/dbus>. > Hopefully someone is able to shed some light on what is going wrong? > > I don’t *think* there is an issue with the python side of things as I can > execute fine with d-feet but the source for this is also available on > GitHub <https://github.com/ssokolow/quicktile>. > > Many Thanks, > Fabrizio Lungo > > http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > > |
|
From: Fabrizio L. <fa...@lu...> - 2014-12-22 10:14:11
|
I am not sure if this is a bug with dbus-cxx or if I am doing something wrong. I am trying to use dbus-cxx to send a message to a dbus-python application (quicktile). Using d-feet I can see that the signature is doCommand (String command) |-> (Boolean arg_1). In cpp I have created a wrapper class for the method: *quickTileProxy.h <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.h>* #define QT_DBUS_NAME "com.ssokolow.QuickTile"#define QT_OBJECT_PATH "/com/ssokolow/QuickTile"#define QT_INTERFACE "com.ssokolow.QuickTile" class quickTileProxy { DBus::ObjectProxy::pointer object;public: DBus::MethodProxy<bool, std::string>& doCommand; quickTileProxy(DBus::Connection::pointer connection);private: }; *quickTileProxy.cpp <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/quickTileProxy.cpp>* #include <dbus-cxx.h>#include "quickTileProxy.h" quickTileProxy::quickTileProxy(DBus::Connection::pointer connection) : object(connection->create_object_proxy(QT_DBUS_NAME, QT_OBJECT_PATH)), doCommand(*(object->create_method<bool,std::string>(QT_INTERFACE,"doCommand"))) { } This is instantiated with: *opensnap.cpp:181 <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L181>* qt_proxy = new quickTileProxy(connection); and doCommand is called with the line: *opensnap.cpp:40 <https://github.com/flungo/opensnap-quicktile/blob/feature/dbus/src/opensnap.cpp#L40>* rtn = qt_proxy->doCommand(args); The command runs successfully on the quicktile daemon and the action is performed however at this point the code hangs. Using gdb I have traced the point that the code hangs to between lines 127 and 128 of /usr/include/dbus-cxx-0.8/dbus-cxx/methodproxy.h: ReturnMessage::const_pointer retmsg = this->call( _callmsg ); T_return _retval; The disassembly shows that it is in a __lll_lock_wait and would appear to be deadlocked. The full disassembly: __lll_lock_wait() __lll_lock_wait+28: mov %edx,%eax __lll_lock_wait+30: xchg %eax,(%rdi) __lll_lock_wait+32: test %eax,%eax __lll_lock_wait+34: jne 0x7ffff2eb4115 <__lll_lock_wait+21> __lll_lock_wait+36: pop %rdx __lll_lock_wait+37: pop %r10 __lll_lock_wait+39: retq I am currently using *aur/dbus-cxx 0.8.0-2* (which I think is the latest) from the Arch Linux AUR. If you would like to browse or download the full source code then it is available from GitHub <https://github.com/flungo/opensnap-quicktile/tree/feature/dbus>. Hopefully someone is able to shed some light on what is going wrong? I don’t *think* there is an issue with the python side of things as I can execute fine with d-feet but the source for this is also available on GitHub <https://github.com/ssokolow/quicktile>. Many Thanks, Fabrizio Lungo http://yours.sincere.ly/flungo/ <http://sincere.ly/flungo/> |
|
From: <emm...@or...> - 2013-11-20 17:09:29
|
Hello, Here's a patch to the example code so that it triggers the compilation error. Apparently, overload resolution in Message::operator<< chooses ::operator<<( DBus::MessageAppendIterator&, const SomeType& ), while it prefers the less specific DBus::MessageAppendIterator::operator<<(const T&) in MethodProxy<...>::operator(). However messageappenditerator.h is included before either methods are even declared (I checked the preprocessor output) so I would expect the compiler to have the same behavior in both of them. I also tried forward-declaration of class MessageAppendIterator and operator<<(DBus::MessageAppendIterator&, struct timeval) before including any dbus-cxx headers but that would not work either. Moving the user-defined operator<< to the DBus namespace also solves nothing, so it does not seem to be a problem with function name lookup. I find myself puzzled. -- Emmanuel ________________________________________ De : Robert Middleton [rmi...@sy...] Date d'envoi : mercredi 20 novembre 2013 04:31 À : RAULO-KUMAGAI Emmanuel NRS Cc : dbu...@li... Objet : Re: [Dbus-cxx-users] MessageAppendIterator::operator<< begin called instead of overload defined in global namespace Interesting observation, I'm guessing that what's going on is because of how the includes are being parsed, the second parameter is being compiled as a separate compilation unit or something. Could you attach the sources that you've been using to test this? I think I understand what you're saying but I want to be sure. One possible solution would be to not use operator<< and operator>> in order to do serialization/deserialization. Personally, I'm not a fan of overloading operators, but it works so I haven't done anything with it. I almost think that maybe the best solution here would be to re-design how the messages are built up, so that it would be possible to add in different types of appenders into the system - as it stands right now, defining custom types is rather convoluted(and apparently prone to errors). -Robert Middleton On Mon, Nov 18, 2013 at 9:03 AM, <emm...@or...<mailto:emm...@or...>> wrote: Hello, Lately, I have been playing around with DBus-cxx and user-defiend types. When working with custom types in DBus-cxx, I found that MethodProxy::operator() will call the template member operator<< in MessageAppendIterator instead of the user-defined overload in the global namespace *starting*with*the*second*method*parameter*. MessageAppendIterator::operator<< in turn attempts to call the MessageAppendIterator::append overload which does not exist and raises a compiler error. This happens at least with GCC 4.6.3 The bug can be reproduced by slightly modifying the time client/server example in examples/basics/types. Just add *two* dummy parameters of type struct timeval to the now() method to trigger this. As a fix, I propose that MessageAppendIterator::operator<< be modified to delegate its implementation to a template struct with a static append() method. The user would then have to specialize this struct instead of defining his/her own operator<< for custom types. Lazy instantiation of operator<< would ensure that the appropriate specialization is used. This would also have the benefit of allowing one partial specialization to be used for a broad range of types. As an example, I'm using this to automatically serialize introspectable types (e.g. through boost::enable_if<is_introspectable<T>>::type). Please see attached patch for the proposed solution. This is a patch against dbus-cxx 0.8.0. By the way, it would also be nice if deserialization also worked that way. Maybe serialization, deserialization and signature could all rely on a single traits structure as a default? Regards, -- Emmanuel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Dbus-cxx-users mailing list Dbu...@li...<mailto:Dbu...@li...> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
From: Robert M. <rmi...@sy...> - 2013-11-20 04:01:28
|
Interesting observation, I'm guessing that what's going on is because of how the includes are being parsed, the second parameter is being compiled as a separate compilation unit or something. Could you attach the sources that you've been using to test this? I think I understand what you're saying but I want to be sure. One possible solution would be to not use operator<< and operator>> in order to do serialization/deserialization. Personally, I'm not a fan of overloading operators, but it works so I haven't done anything with it. I almost think that maybe the best solution here would be to re-design how the messages are built up, so that it would be possible to add in different types of appenders into the system - as it stands right now, defining custom types is rather convoluted(and apparently prone to errors). -Robert Middleton On Mon, Nov 18, 2013 at 9:03 AM, <emm...@or...> wrote: > Hello, > > Lately, I have been playing around with DBus-cxx and user-defiend types. > > When working with custom types in DBus-cxx, I found that > MethodProxy::operator() will call the template member operator<< in > MessageAppendIterator instead of the user-defined overload in the global > namespace *starting*with*the*second*method*parameter*. > MessageAppendIterator::operator<< in turn attempts to call the > MessageAppendIterator::append overload which does not exist and raises a > compiler error. This happens at least with GCC 4.6.3 > > The bug can be reproduced by slightly modifying the time client/server > example in examples/basics/types. Just add *two* dummy parameters of type > struct timeval to the now() method to trigger this. > > As a fix, I propose that MessageAppendIterator::operator<< be modified to > delegate its implementation to a template struct with a static append() > method. The user would then have to specialize this struct instead of > defining his/her own operator<< for custom types. Lazy instantiation of > operator<< would ensure that the appropriate specialization is used. > > This would also have the benefit of allowing one partial specialization to > be used for a broad range of types. As an example, I'm using this to > automatically serialize introspectable types (e.g. through > boost::enable_if<is_introspectable<T>>::type). > > Please see attached patch for the proposed solution. This is a patch > against dbus-cxx 0.8.0. > > By the way, it would also be nice if deserialization also worked that way. > Maybe serialization, deserialization and signature could all rely on a > single traits structure as a default? > > Regards, > > -- > Emmanuel > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > > |
|
From: <emm...@or...> - 2013-11-18 14:21:44
|
Hello, Lately, I have been playing around with DBus-cxx and user-defiend types. When working with custom types in DBus-cxx, I found that MethodProxy::operator() will call the template member operator<< in MessageAppendIterator instead of the user-defined overload in the global namespace *starting*with*the*second*method*parameter*. MessageAppendIterator::operator<< in turn attempts to call the MessageAppendIterator::append overload which does not exist and raises a compiler error. This happens at least with GCC 4.6.3 The bug can be reproduced by slightly modifying the time client/server example in examples/basics/types. Just add *two* dummy parameters of type struct timeval to the now() method to trigger this. As a fix, I propose that MessageAppendIterator::operator<< be modified to delegate its implementation to a template struct with a static append() method. The user would then have to specialize this struct instead of defining his/her own operator<< for custom types. Lazy instantiation of operator<< would ensure that the appropriate specialization is used. This would also have the benefit of allowing one partial specialization to be used for a broad range of types. As an example, I'm using this to automatically serialize introspectable types (e.g. through boost::enable_if<is_introspectable<T>>::type). Please see attached patch for the proposed solution. This is a patch against dbus-cxx 0.8.0. By the way, it would also be nice if deserialization also worked that way. Maybe serialization, deserialization and signature could all rely on a single traits structure as a default? Regards, -- Emmanuel _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
From: <emm...@or...> - 2013-10-08 15:36:27
|
Here you are. The patch is catching standard exceptions inside of DBus::Method<>::handle_call_message() within method.h (well, method.h.m4). That worked for me but there might be other places where the code needs updating (method_impl.h maybe? I couldn't find it included anywhere). On the proxy/client side, the error can be caught as a DBus::Error::pointer. The what() of the oritinal exception is then contained in the message() of the DBus::Error. -- Emmanuel Raulo-Kumagai ________________________________________ De : Robert Middleton [rmi...@sy...] Date d'envoi : mardi 8 octobre 2013 15:01 À : RAULO-KUMAGAI Emmanuel NRS Cc : dbu...@li... Objet : Re: [Dbus-cxx-users] Feature request with patch proposal: propagate exceptions through DBus You can attach patches here. I'll take a look at it, and see about putting it in. On a side note, I have been meaning to do exception handling for a while now, but I haven't gotten around to it. I know that dbus-java will catch all exceptions and then return an error message back onto the bus if an exception is caught or NULL is returned from a function. -Robert Middleton On Tue, Oct 8, 2013 at 5:24 AM, <emm...@or...<mailto:emm...@or...>> wrote: Hello, DBus provides the possibility for a method call to throw an error. However DBus-cxx in its current shape doesn't mirror this feature; message call handlers don't catch exceptions so, if an error condition arises in a slot bound to a DBus method, the exception is bubbled all the way up to the dispatcher and stops it. A possibility is of course to use return codes in APIs exposed over DBus rather than throw exceptions but that doesn't feel like the way of modern C++. My proposal would be to call the slot bound to a DBus method in a try block and catch std::exception&. In the case an exception occured, a DBus error message can be sent as a reply to the caller. I made a patch for that purpose, which I can provide. It might be a little quick & dirty though, as I had to change the signature of one of the DBus::ErrorMessage constructors (the one that constructs a reply) to accept a Message::const_pointer as first argument. I don't know if the mailing list is the right place to send the patch. Thanks in advance for your support. Regards, -- Emmanuel Raulo-Kumagai _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Dbus-cxx-users mailing list Dbu...@li...<mailto:Dbu...@li...> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
From: Robert M. <rmi...@sy...> - 2013-10-08 13:32:09
|
You can attach patches here. I'll take a look at it, and see about putting it in. On a side note, I have been meaning to do exception handling for a while now, but I haven't gotten around to it. I know that dbus-java will catch all exceptions and then return an error message back onto the bus if an exception is caught or NULL is returned from a function. -Robert Middleton On Tue, Oct 8, 2013 at 5:24 AM, <emm...@or...> wrote: > Hello, > > DBus provides the possibility for a method call to throw an error. > However DBus-cxx in its current shape doesn't mirror this feature; message > call handlers don't catch exceptions so, if an error condition arises in a > slot bound to a DBus method, the exception is bubbled all the way up to the > dispatcher and stops it. > A possibility is of course to use return codes in APIs exposed over DBus > rather than throw exceptions but that doesn't feel like the way of modern > C++. > > My proposal would be to call the slot bound to a DBus method in a try > block and catch std::exception&. > In the case an exception occured, a DBus error message can be sent as a > reply to the caller. > > I made a patch for that purpose, which I can provide. It might be a little > quick & dirty though, as I had to change the signature of one of the > DBus::ErrorMessage constructors (the one that constructs a reply) to accept > a Message::const_pointer as first argument. > I don't know if the mailing list is the right place to send the patch. > > Thanks in advance for your support. > Regards, > > -- > Emmanuel Raulo-Kumagai > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > |
|
From: <emm...@or...> - 2013-10-08 09:42:22
|
Hello, DBus provides the possibility for a method call to throw an error. However DBus-cxx in its current shape doesn't mirror this feature; message call handlers don't catch exceptions so, if an error condition arises in a slot bound to a DBus method, the exception is bubbled all the way up to the dispatcher and stops it. A possibility is of course to use return codes in APIs exposed over DBus rather than throw exceptions but that doesn't feel like the way of modern C++. My proposal would be to call the slot bound to a DBus method in a try block and catch std::exception&. In the case an exception occured, a DBus error message can be sent as a reply to the caller. I made a patch for that purpose, which I can provide. It might be a little quick & dirty though, as I had to change the signature of one of the DBus::ErrorMessage constructors (the one that constructs a reply) to accept a Message::const_pointer as first argument. I don't know if the mailing list is the right place to send the patch. Thanks in advance for your support. Regards, -- Emmanuel Raulo-Kumagai _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
From: Robert M. <rmi...@sy...> - 2013-09-10 18:28:23
|
Once I finish my re-work of the tools, I'll have a new version out; it should be in the next week or two. I'll work on the warnings for the next release. -Robert Middleton On Tue, Sep 10, 2013 at 11:46 AM, Christoph Pramberger < pra...@gm...> wrote: > Okay thank you for your answer. > > > > Do you also plan to release a new version soon? > > > > Best regards > > > > *Von:* Robert Middleton [mailto:rmi...@sy...] > *Gesendet:* Dienstag, 10. September 2013 17:00 > *An:* Christoph Pramberger > *Cc:* dbu...@li... > *Betreff:* Re: [Dbus-cxx-users] ‘std::string DBus::Method<T_return, > T_arg1, T_arg2, sigc::nil, sigc::nil, sigc::nil, sigc::nil, > sigc::nil>::introspect(int) const [with T_return = double, T_arg1 = double, > T_arg2 = double]’ - warning: ‘type’ may be used uninitialized > > > > Christoph, > > > > So basically what's going on here is that GCC is probably being a little > too helpful in this case. It's complaining that it's going to call a > method with an uninitialized variable, but the only reason we need the > variable is to figure out which overloaded method is called, which means > that the variable is never actually used. It does it this way to exploit > the recursive call in order to build up the proper D-Bus signature - > although now that I think about it, it may be possible to use TMP to > achieve the same effect...(I will look into it sometime this week/weekend. > I'm currently updating the dbus-cxx tools) > > > > You could try: > > > http://stackoverflow.com/questions/965093/selectively-disable-gcc-warnings-for-only-part-of-a-translation-unit > > > > -Robert Middleton > > > > On Tue, Sep 10, 2013 at 3:45 AM, Christoph Pramberger < > pra...@gm...> wrote: > > Hello, > > currently I'm using the SVN repository of dbus-cxx. > > If I compile the example programm "server.cpp" I get following warnings: > > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h: In member function > ‘std::string DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, > sigc::nil, sigc::nil, sigc::nil>::introspect(int) const [with T_return = > double, T_arg1 = double, T_arg2 = double]’: > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:290: warning: ‘type’ may > be used uninitialized in this function > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:294: warning: ‘arg1’ may > be used uninitialized in this function > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:298: warning: ‘arg2’ may > be used uninitialized in this function > > Does anybody know how I can fix that, because I mostly compile my code > with "-Wall -Werror". > > Thanks > > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > > > |
|
From: Robert M. <rmi...@sy...> - 2013-09-10 16:01:38
|
Christoph, So basically what's going on here is that GCC is probably being a little too helpful in this case. It's complaining that it's going to call a method with an uninitialized variable, but the only reason we need the variable is to figure out which overloaded method is called, which means that the variable is never actually used. It does it this way to exploit the recursive call in order to build up the proper D-Bus signature - although now that I think about it, it may be possible to use TMP to achieve the same effect...(I will look into it sometime this week/weekend. I'm currently updating the dbus-cxx tools) You could try: http://stackoverflow.com/questions/965093/selectively-disable-gcc-warnings-for-only-part-of-a-translation-unit -Robert Middleton On Tue, Sep 10, 2013 at 3:45 AM, Christoph Pramberger < pra...@gm...> wrote: > Hello, > > currently I'm using the SVN repository of dbus-cxx. > > If I compile the example programm "server.cpp" I get following warnings: > > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h: In member function > ‘std::string DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, > sigc::nil, sigc::nil, sigc::nil>::introspect(int) const [with T_return = > double, T_arg1 = double, T_arg2 = double]’: > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:290: warning: ‘type’ may > be used uninitialized in this function > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:294: warning: ‘arg1’ may > be used uninitialized in this function > /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:298: warning: ‘arg2’ may > be used uninitialized in this function > > Does anybody know how I can fix that, because I mostly compile my code > with "-Wall -Werror". > > Thanks > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > > |
|
From: Christoph P. <pra...@gm...> - 2013-09-10 15:46:24
|
Okay thank you for your answer. Do you also plan to release a new version soon? Best regards Von: Robert Middleton [mailto:rmi...@sy...] Gesendet: Dienstag, 10. September 2013 17:00 An: Christoph Pramberger Cc: dbu...@li... Betreff: Re: [Dbus-cxx-users] 'std::string DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::introspect(int) const [with T_return = double, T_arg1 = double, T_arg2 = double]' - warning: 'type' may be used uninitialized Christoph, So basically what's going on here is that GCC is probably being a little too helpful in this case. It's complaining that it's going to call a method with an uninitialized variable, but the only reason we need the variable is to figure out which overloaded method is called, which means that the variable is never actually used. It does it this way to exploit the recursive call in order to build up the proper D-Bus signature - although now that I think about it, it may be possible to use TMP to achieve the same effect...(I will look into it sometime this week/weekend. I'm currently updating the dbus-cxx tools) You could try: http://stackoverflow.com/questions/965093/selectively-disable-gcc-warnings-f or-only-part-of-a-translation-unit -Robert Middleton On Tue, Sep 10, 2013 at 3:45 AM, Christoph Pramberger <pra...@gm...> wrote: Hello, currently I'm using the SVN repository of dbus-cxx. If I compile the example programm "server.cpp" I get following warnings: /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h: In member function 'std::string DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::introspect(int) const [with T_return = double, T_arg1 = double, T_arg2 = double]': /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:290: warning: 'type' may be used uninitialized in this function /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:294: warning: 'arg1' may be used uninitialized in this function /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:298: warning: 'arg2' may be used uninitialized in this function Does anybody know how I can fix that, because I mostly compile my code with "-Wall -Werror". Thanks ---------------------------------------------------------------------------- -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111 <http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > &iu=/4140/ostg.clktrk _______________________________________________ Dbus-cxx-users mailing list Dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users |
|
From: Christoph P. <pra...@gm...> - 2013-09-10 07:45:25
|
Hello, currently I'm using the SVN repository of dbus-cxx. If I compile the example programm "server.cpp" I get following warnings: /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h: In member function ‘std::string DBus::Method<T_return, T_arg1, T_arg2, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::introspect(int) const [with T_return = double, T_arg1 = double, T_arg2 = double]’: /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:290: warning: ‘type’ may be used uninitialized in this function /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:294: warning: ‘arg1’ may be used uninitialized in this function /usr/local/include/dbus-cxx-0.7/dbus-cxx/method.h:298: warning: ‘arg2’ may be used uninitialized in this function Does anybody know how I can fix that, because I mostly compile my code with "-Wall -Werror". Thanks |
|
From: Robert M. <rmi...@sy...> - 2013-05-11 13:16:47
|
Jon, You should be able to use 0.7, although the newest SVN revision has had a bunch of fixes to it to make it more stable and support more dbus objects. I would recommend using the latest SVN revision. I haven't gotten around to releasing a 0.8, since I've made some changes which don't go in both directions(i.e. you can send Dictionaries, but you can't receive Dictionaries if I remember correctly) -Robert Middleton On Fri, May 10, 2013 at 2:33 PM, Jonathan Nichols < jni...@al...> wrote: > Hello, > > I noticed that the 0.7 release of dbus-cxx was in 2010, but the svn > repository has more recent code. If I'm starting a new project, should I > use the 0.7 version, or whatever is on svn? Or something else? > > Regards, > > jon > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > |
|
From: Jonathan N. <jni...@al...> - 2013-05-10 18:33:10
|
Hello,
I noticed that the 0.7 release of dbus-cxx was in 2010, but the svn
repository has more recent code. If I'm starting a new project, should I
use the 0.7 version, or whatever is on svn? Or something else?
Regards,
jon
|
|
From: Robert M. <rmi...@sy...> - 2012-11-09 14:19:50
|
Thanks for the patch; I'll see about putting it SVN this weekend. I haven't figured out how to get autotools to recognize C++ shared pointers(mostly due to not being familiar with autotools), I've just overridden it after generating configure. -Robert Middleton On Fri, Nov 9, 2012 at 1:43 AM, Andrew Montag <ajm...@gm...> wrote: > Hello all, > > I am just getting started with dbus-cxx and had some issues building it > (the same issues as this post<http://sourceforge.net/mailarchive/forum.php?thread_name=4C26C651.1040305%40darenscotwilson.com&forum_name=dbus-cxx-users>from 2 years ago). > > I have solved the problem, and have attached my patch. > > Here is what I ran to install: > > sudo apt-get -y install libdbus-1-dev automake libtool > svn co > https://dbus-cxx.svn.sourceforge.net/svnroot/dbus-cxx/trunk/dbus-cxx > cd dbus-cxx > ./autogen.sh > ./configure CXXFLAGS="-std=c++0x" > patch -p0 -i ../patch_dbus-cxx.patch > make > sudo make install > > I am running Ubuntu 12.04 with g++ 4.6 and am using boost's shared > pointers (because autotools couldn't find my c++0x ones I guess). > > Let me know if you want any more details. Oh, and thanks for the really > nice library! > > -Andrew Montag > https://sites.google.com/site/andrewmontag > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Dbus-cxx-users mailing list > Dbu...@li... > https://lists.sourceforge.net/lists/listinfo/dbus-cxx-users > > |
|
From: Robert M. <rmi...@sy...> - 2012-02-25 15:52:01
|
Not sure if you got my last e-mail, but yes if you could add me to the project I can commit what changes we have. E-mail me directly. Quick list of bugfixes that we've done: -hang on method calls that return void(possibly fixed, I noticed an issue with it the other day) -Updated dispatcher to continue on if select() fails because of an interrupted system call(apparently this happens when the program receives a signal and it's handled) -forced use of C++0x smart pointers as boost would throw errors on our system. May be a problem with the boost library version. -If you remove a signal callback, you won't receive that signal anymore(your program would never receive the signal again, but the D-Bus would still send out the signal to you) -changed PendingCall to not callback if there are no more references to it(this could occur if you used dbus_connecton->send_with_reply_async() and didn't save the pointer that you got back - your callback would be (most likely) deconstructed by the time the D-Bus returned a reply) -added variants -fixed a bug where a segfault would occur if the interface that was called was NULL -some better error handling mechanisms so that we won't exit if something bad happens. This has to do with calling remote methods when an error is thrown from the remote method. -Robert Middleton On Wed, Feb 22, 2012 at 5:31 PM, Rick L. Vinyard, Jr. <rvi...@cs...>wrote: > Just haven't had time. > > I'll add you to the project and give you access to the repo if you want. > > Robert Middleton wrote: > > I noticed yesterday that somebody had posted a message asking if dbus-cxx > > was still being maintained. Rick said that he'd commit stuff that was > > tested, so what's the deal for that stuff to be tested? We've been using > > dbus-cxx for well over a year now, and we've fixed quite a few bugs in > > that > > time(we posted on the dev lists a year ago regarding Variants). > > > > -Robert Middleton > > > > > |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2012-02-22 23:07:10
|
Just haven't had time. I'll add you to the project and give you access to the repo if you want. Robert Middleton wrote: > I noticed yesterday that somebody had posted a message asking if dbus-cxx > was still being maintained. Rick said that he'd commit stuff that was > tested, so what's the deal for that stuff to be tested? We've been using > dbus-cxx for well over a year now, and we've fixed quite a few bugs in > that > time(we posted on the dev lists a year ago regarding Variants). > > -Robert Middleton > |
|
From: Robert M. <rmi...@sy...> - 2012-02-22 22:12:41
|
I noticed yesterday that somebody had posted a message asking if dbus-cxx was still being maintained. Rick said that he'd commit stuff that was tested, so what's the deal for that stuff to be tested? We've been using dbus-cxx for well over a year now, and we've fixed quite a few bugs in that time(we posted on the dev lists a year ago regarding Variants). -Robert Middleton |
|
From: Rick L. V. Jr. <rvi...@cs...> - 2011-12-01 19:55:19
|
I haven't had time to work on it for awhile, but if anyone wants to submit tested patches I'll commit them. Ryan Lewis wrote: > Hi, > > is this code still maintained? I want to use it in an application and > when I just include the header and compile with pkg-config I get all > sorts of bugs. > > I can send the code and compile line with errors, if this is still a > maintained project. > > -rhl > -- Rick |
|
From: Ryan L. <me...@ry...> - 2011-12-01 17:37:24
|
Hi, is this code still maintained? I want to use it in an application and when I just include the header and compile with pkg-config I get all sorts of bugs. I can send the code and compile line with errors, if this is still a maintained project. -rhl |
|
From: camillo s. <cam...@gm...> - 2011-01-04 13:31:13
|
Hi, recently i implemented a DBus::Object method in a DBus server and a corresponding MethodProxy in my DBus client. Since i didnt need a return value i used the signature void CMyClass::myMethod(string msg, int x, int y); thus calling something like pObj->create_method<void,string,int,int>(interfacename, methodname, sigc::mem_fun(*this, &CMyClass::myMethod)); at the server and accordingly DBus::MethodProxy<void,string,int,int>::pointer pProxyMethod = pObjProxy->create_method<void,string,int,int>(interfacename,methodname); at the client side. However I frequently encountered some unknown exceptions when issuing a proxy call prior to shutting down my threads (objects were still valid at that time), i.e. the call hung some time and then threw an unspecified exception. When I changed the signature of my method and proxy from void to return an int everything worked well. Anybody also observed something therelike or some explanations for this strange behaviour? Regards camillo |
|
From: Kesselring, D. <Dav...@it...> - 2010-11-30 19:59:01
|
I am trying to build the example glibmm_caller_dispatched with the Timesys embedded Linux environment. When I build it I get the following error from a line in dbus-cxx/error.h. Source line: typedef DBusCxxPointer<Error> pointer; Error: ISO C++ forbids delcaration of 'shared_ptr' with no type Any suggestions will be appreciated. Regards, David Kesselring Itron, Inc. Dav...@it... Mobile: +1-919-349-1079 |
|
From: camillo s. <cam...@gm...> - 2010-07-13 08:06:31
|
Hi there,
I'm starting to develop a distributed application using dbus-cxx-0.7.0. In
principle things work quite well, however when digging a bit deeper I run
into the following problems where up to now neither the examples shipped
with the project nor goggling around provided me an answer.
First I'd like to properly handle the case of calling a method-proxy in my
test-client without the server running. To do so I enclosed the proxy call
with a try-catch block like this
> * int setTimerRel(int pid, int timerId, long initDelay, long deltaT, int
> repCount)*
> * {*
> * try*
> * {*
> * cout << "CTSMProxy setTimerRel" << endl;*
> * return (*m_methodSetTimerRel)(pid, timerId, initDelay, deltaT,
> repCount);*
> * }*
> * catch (exception &e) { cerr << "exception: " << e.what() << endl;
> return -1;}*
> * catch (...) { cerr << "caught something else" << endl; return -1; }*
> * }*
>
When this method is called without the server running I always run into the
catch(...) block which provides me no information about the exception. I
also tried to add a third catch-block using one of the dbus-cxx provided
Error classes, however to no avail which is obvious since these classes
derive from std:exception which is caught neither. Are there some examples
how to proceed there correctly ?
The second problem I run into is when (with server running now) I repeatedly
issue proxy-calls in a loop, say up to 10 times. Then some calls work fine
but then a timeout occurs and the proxy returns again with the catch(...).
How about to handle such stress scenarios in an orderly way?
Thx + regards
camillo
|
1 message has been excluded from this view by a project administrator.
