Menu
▾
▴
Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?
|
From: Freyensee, J. P <jam...@in...> - 2009-12-10 00:28:36
|
Was my last reply received? If not, I copied my reply and re-sending it.
Thanks,
Jay
-----------------------------------------------
From: Freyensee, James P
Sent: Wednesday, December 02, 2009 1:29 PM
To: Andreas Volz
Subject: RE: [dbus-cplusplus-devel] contributing a submission to the project...best way?
Nope, actually I didn't see this email. So thanks for sending this my way.
Our patch and change all works. I can compile it and I am currently using it. The caveat is I'm compiling it in Moblin.
I see:
Connection Connection::SystemBus(Dispatcher* dispatcher )
{
return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);
}
in the libdbus-c++ code I'm using which we gave you the patch. We use Connection::SystemBus(Dispatcher)
call a lot.
For example:
//new default dispatcher used by SystemBus() ...
dispatcher = new DBus::BusDispatcher();
try{
DBus::Connection conn = DBus::Connection::SystemBus(dispatcher);
}
Now DBus::BusDispatcher() will return an object of 'BusDispatcher' which is in the DBus namespace and is a child of the public Dispatcher class.
The Dispatcher class looks like a base class that is inside the DBus namespace.
I think our Connection constructor is matching up with Connection constructor found in include/dbus-c++/connection.h:
class DXXAPI Connection
{
public:
static Connection SystemBus(Dispatcher* dispatcher = default_dispatcher );
I also see:
Connection(Private *, Dispatcher * dispatcher = default_dispatcher);
which is probably matching the Connection::SystemBus() call in question, the
"return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);", yes??
Jay
-----Original Message-----
From: Andreas Volz [mailto:li...@br...]
Sent: Wednesday, December 02, 2009 11:40 AM
To: Freyensee, James P
Subject: Fw: [dbus-cplusplus-devel] contributing a submission to the project...best way?
Hello James,
did you get this E-Mail from the list?
regards
Andreas
Anfang der weitergeleiteten Nachricht:
Datum: Sun, 29 Nov 2009 17:36:46 +0100
Sender: Andreas Volz <li...@br...>
Empfänger: dbu...@li...
Titel: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
Am Fri, 20 Nov 2009 09:58:38 -0800 schrieb Freyensee, James P:
> On the examples, I don't think they are important. I know changes
> were made just to get them to compile so if the examples compile for
> you, then that's good :-).
I didn't try it. I hope you'll give me feedback if it works for you.
> On:
> >connection.h/connection.cpp:
> >extern DXXAPI Dispatcher* default_dispatcher;
> >...and all changes specific to the change that Connection
> >constructors have a new parameter Dispatcher* dispatcher.
>
> >I've a raw idea what's the reason for it. But could you explain what
> >was the main idea behind this change.
>
> I cannot give you an exact reason, but I can give you a general
> reason. We want a safeguard of being able to set up a single default
> dispatch mechanism for all Dbus connections we try to establish in a
> project. For example, there is this project we have open-sourced for
> a 3rd party:
>
> https://sourceforge.net/projects/optelephony
>
> that heavily uses this concept when trying to establish an initial
> session with the 3rd party's product:
>
> // from https://sourceforge.net/projects/optelpehony
> bool TelSessionClient::initSessionClient(){
>
> if(!mDispatcher){
> mDispatcher = new DBus::Glib::BusDispatcher();
> DBus::default_dispatcher = mDispatcher;
> mDispatcher->attach(NULL);
> }
>
> if(!mConnection){
> try{
> mConnection = new DBus::Connection(DBus::Connection::SystemBus());
> }
> catch (DBus::Error e) {
> printf("Can not connect to the SystemBus : %s\n",e.message());
> return 0;
> }
> mConnection->set_timeout(120*1000);
> }
>
> if(!cb)
> cb = new TelCallBack(*mConnection);
>
> if(!server)
> try{
> server = new TelServerTAPI (*mConnection);
> }
> catch (DBus::Error e){
> return false;
> }
> mDispatcher->enter();
> return true;
> }
I've a little problem with this patch. See here:
before:
Connection Connection::SystemBus()
{
return Connection(new Private(DBUS_BUS_SYSTEM));
}
after patch:
Connection Connection::SystemBus(Dispatcher* dispatcher )
{
return Connection(new Private(DBUS_BUS_SYSTEM),dispatcher);
}
But look at Private:
Private(DBusConnection *, Server::Private * = NULL);
Private(DBusBusType);
In "Before" the second constructor with DBusBusType was called before.
But now you call a Constructor with (DBusBusType, Dispatcher*) what
doesn't seem to have such a constructor. I didn't compile your sources,
but does this compile? Or do I have some merging problem in Private
here?
> On:
> >generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
>
> >What are exactly the reason of these change? Looks for me like some
> >sort of Async method support. Could you spend some more words here?
>
> that actually did not come from the change we wanted to apply to your
> project. What looks like has happened is these files used to be in
> xml2cpp.cpp and were separated out at some point. I believe the
> commit ID on the git tree when this happened was c2b8cb (maybe??). I
> don't think this is really a part of the libdbus-c++ functionality as
> is a part of a tool to create .cpp code from .xml code, so I don't
> believe this effects us at all.
Ok. Async support is on my TODO list. So I'll later take a look on it.
> On:
>
> > eventloop.cpp:
> > DefaultMutex::DefaultMutex()
> > {
>
> > pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > _mutex = recmutex;
> > //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > //pthread_mutex_init(&_mutex, NULL);
> >}
>
> We don't seem to use the class DefaultMutex or the methods where the
> DefaultMutex instance variable _mutex_p is used (queue_connection(),
> dispatch_pending()). And I know we did not comment that code out. I
> could tell you a possible reason for why
> PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there. It prevents a
> certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used
> instead. If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple
> calls of pthread_mutex_lock without calling pthread_mutex_unlock by
> the owner of the mutex could result in dead-lock. I have no idea if
> the original intent was to be able to use this code recursively, but
> it may be a good idea to leave this alone (well, with the exception
> of removing the commented-out lines)?
I reviewed the code and couldn't see a reason for using the recursive
mutex code here. So I just did this:
DefaultMutex(bool recursive = false);
DefaultMutex::DefaultMutex(bool recursive)
{
if (recursive)
{
pthread_mutex_t recmutex =
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP; _mutex = recmutex;
}
else
{
pthread_mutex_init(&_mutex, NULL);
}
}
So as default we've the old implementation. If you ever see a problem
with it we may change to the recursive mutex as default. Is this ok for
you? How ever, I commited this.
regards
Andreas Volz
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 Nov 2009 09:58:38 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: "dbu...@li..."
<dbu...@li...>
Cc: "Yokoyama, Caz" <caz...@in...>
Message-ID:
<A26...@or...>
Content-Type: text/plain; charset="us-ascii"
Andreas:
Thanks for your work. It is very much appreciated.
On the examples, I don't think they are important. I know changes were made just to get them to compile so if the examples compile for you, then that's good :-).
On:
>connection.h/connection.cpp:
>extern DXXAPI Dispatcher* default_dispatcher;
>...and all changes specific to the change that Connection constructors
>have a new parameter Dispatcher* dispatcher.
>I've a raw idea what's the reason for it. But could you explain what
>was the main idea behind this change.
I cannot give you an exact reason, but I can give you a general reason. We want a safeguard of being able to set up a single default dispatch mechanism for all Dbus connections we try to establish in a project. For example, there is this project we have open-sourced for a 3rd party:
https://sourceforge.net/projects/optelephony
that heavily uses this concept when trying to establish an initial session with the 3rd party's product:
// from https://sourceforge.net/projects/optelpehony
bool TelSessionClient::initSessionClient(){
if(!mDispatcher){
mDispatcher = new DBus::Glib::BusDispatcher();
DBus::default_dispatcher = mDispatcher;
mDispatcher->attach(NULL);
}
if(!mConnection){
try{
mConnection = new DBus::Connection(DBus::Connection::SystemBus());
}
catch (DBus::Error e) {
printf("Can not connect to the SystemBus : %s\n",e.message());
return 0;
}
mConnection->set_timeout(120*1000);
}
if(!cb)
cb = new TelCallBack(*mConnection);
if(!server)
try{
server = new TelServerTAPI (*mConnection);
}
catch (DBus::Error e){
return false;
}
mDispatcher->enter();
return true;
}
On:
>generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
>What are exactly the reason of these change? Looks for me like some sort
>of Async method support. Could you spend some more words here?
that actually did not come from the change we wanted to apply to your project. What looks like has happened is these files used to be in xml2cpp.cpp and were separated out at some point. I believe the commit ID on the git tree when this happened was c2b8cb (maybe??). I don't think this is really a part of the libdbus-c++ functionality as is a part of a tool to create .cpp code from .xml code, so I don't believe this effects us at all.
On:
> eventloop.cpp:
> DefaultMutex::DefaultMutex()
> {
> pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> _mutex = recmutex;
> //_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> //pthread_mutex_init(&_mutex, NULL);
>}
We don't seem to use the class DefaultMutex or the methods where the DefaultMutex instance variable _mutex_p is used (queue_connection(), dispatch_pending()). And I know we did not comment that code out. I could tell you a possible reason for why PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is there. It prevents a certain deadlock case if PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used instead. If PTHREAD_RECURSIVE_MUTEX_INITIALIZER was used, multiple calls of pthread_mutex_lock without calling pthread_mutex_unlock by the owner of the mutex could result in dead-lock. I have no idea if the original intent was to be able to use this code recursively, but it may be a good idea to leave this alone (well, with the exception of removing the commented-out lines)?
I think I covered all of your concerns?? Please let me know if I did not. Also, please let me know when the final changes are made. I'm going to pull down the final result and run it with our project.
thanks again,
Jay
------------------------------
Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII
Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project. We verified the merge (from freedesktop)
> works, at least for the product we are using with it. We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):
examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)
connection.h/connection.cpp:
extern DXXAPI Dispatcher* default_dispatcher;
...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.
I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.
connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied
eventloop.cpp:
DefaultMutex::DefaultMutex()
{
pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
_mutex = recmutex;
//_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
//pthread_mutex_init(&_mutex, NULL);
}
What was the reason of doing this?
The rest of the eventloop integration is applied now.
generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?
regards
Andreas
-----Original Message-----
From: dbu...@li... [mailto:dbu...@li...]
Sent: Tuesday, November 17, 2009 4:06 AM
To: dbu...@li...
Subject: dbus-cplusplus-devel Digest, Vol 16, Issue 5
Send dbus-cplusplus-devel mailing list submissions to
dbu...@li...
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
or, via email, send a message with subject or body 'help' to
dbu...@li...
You can reach the person managing the list at
dbu...@li...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dbus-cplusplus-devel digest..."
Today's Topics:
1. Re: contributing a submission to the project...best way?
(Andreas Volz)
2. Re: contributing a submission to the project...best way?
(Freyensee, James P)
3. Re: contributing a submission to the project...best way?
(Freyensee, James P)
4. Re: contributing a submission to the project...best way?
(Andreas Volz)
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Nov 2009 18:45:34 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: "Freyensee, James P" <jam...@in...>
Cc: "Yokoyama, CazX" <caz...@in...>, "Ahmed, Suhail"
<suh...@in...>, "Benis, Robertino"
<rob...@in...>,
dbu...@li...
Message-ID: <20091116184534.6c4b2b02@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII
Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:
Hello James,
ok, I found the ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=25022
There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:
http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B
I wonder because there's a similar ticket on sf.net:
http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684
Are those two tickets connected?
It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...
regards
Andreas
>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project. We verified the merge (from freedesktop)
> works, at least for the product we are using with it. We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
> project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
> Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project. What is the best way to do this? I read on the website we
> > would submit the patch through Bugzilla. Is this still correct? Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you? Use 'git format-patch'? Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >
------------------------------
Message: 2
Date: Mon, 16 Nov 2009 10:07:25 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: Andreas Volz <li...@br...>
Cc: "Yokoyama, Caz" <caz...@in...>, "Ahmed, Suhail"
<suh...@in...>, "Benis, Robertino"
<rob...@in...>,
"dbu...@li..."
<dbu...@li...>
Message-ID:
<5CF...@or...>
Content-Type: text/plain; charset="us-ascii"
Thanks Andreas for looking at this and letting me know.
I was unaware of that sourceforge bug; but it looks like those are the functions we added in this bug and need.
Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?
Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:
Hello James,
ok, I found the ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=25022
There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:
http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B
I wonder because there's a similar ticket on sf.net:
http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684
Are those two tickets connected?
It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...
regards
Andreas
>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project. We verified the merge (from freedesktop)
> works, at least for the product we are using with it. We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
> project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
> Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project. What is the best way to do this? I read on the website we
> > would submit the patch through Bugzilla. Is this still correct? Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you? Use 'git format-patch'? Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >
------------------------------
Message: 3
Date: Mon, 16 Nov 2009 10:39:06 -0800
From: "Freyensee, James P" <jam...@in...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: Andreas Volz <li...@br...>
Cc: "Ahmed, Suhail" <suh...@in...>, "Yokoyama, Caz"
<caz...@in...>, "Benis, Robertino"
<rob...@in...>,
"dbu...@li..."
<dbu...@li...>
Message-ID:
<5CF...@or...>
Content-Type: text/plain; charset="us-ascii"
Andreas:
I am looking at the difference between the two patches. There is a difference in how send_blocking() is getting patched. The sourceforge patch, bug 2701443, changes how the send_blocking() call is used:
static void unregister_function_stub( DBusConnection*, void* );
@@ -323,7 +331,7 @@ Message ObjectProxy::_invoke_method( Cal
call.path(path().c_str());
call.destination(service().c_str());
- return conn().send_blocking(call);
+ return conn().send_blocking(call, get_timeout());
but nowhere in the patch is the send_blocking() call modified to reflect the new parameter 'get_timeout()'. So either send_blocking()'s 2nd parameter in the gitorious branch is already there or there is another patch to add the send_blocking() second parameter.
Our patch makes an adjustment to send_blocking() :
@@ -360,7 +361,11 @@ Message Connection::send_blocking(Message &msg, int timeout)
DBusMessage *reply;
InternalError e;
+ if(this->_timeout != -1)
+ reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, this->_timeout, e);
+ else
reply = dbus_connection_send_with_reply_and_block(_pvt->conn, msg._pvt->msg, timeout, e);
+
Thanks,
Jay Freyensee
UMG
(please excuse the email syntax; broken collarbone)
________________________________________
From: Andreas Volz [li...@br...]
Sent: Monday, November 16, 2009 9:45 AM
To: Freyensee, James P
Cc: dbu...@li...; Yokoyama, CazX; Ahmed, Suhail; Benis, Robertino
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the project...best way?
Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:
Hello James,
ok, I found the ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=25022
There's no "dbus-c++" on fd.org because I was wrong. I moved bug
handling to sourceforge some time ago. Now I've documented this in the
wiki:
http://www.freedesktop.org/wiki/Software/dbus-c%2B%2B
I wonder because there's a similar ticket on sf.net:
http://sourceforge.net/tracker/?func=detail&aid=2701443&group_id=236997&atid=1101684
Are those two tickets connected?
It seems only that libdbus-c++-0.5.2-70009.1.moblin2.patch contains
many moblin specific autotools scripts. And I see changes in the code
generator. This is bad as I don't like to maintain further changes in
the fdo.org code generator. I did many changes in the gitorious branch.
The only reason why I didn't merge them all back to fd.org is the lack
of good unit test to verify the generated code. But I'll take a look
into it...
regards
Andreas
>
> Andreas:
>
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project. We verified the merge (from freedesktop)
> works, at least for the product we are using with it. We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
>
> Thanks,
> Jay
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Nov 2009 22:12:51 +0100
> From: Andreas Volz <li...@br...>
> Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
> project...best way?
> To: dbu...@li...
> Message-ID: <20091107221251.0fa70a84@frodo.mittelerde>
> Content-Type: text/plain; charset=US-ASCII
>
> Am Thu, 5 Nov 2009 10:51:05 -0800 schrieb Freyensee, James P:
>
> Hello Jay,
>
> Great to hear that someone likes to contribute some code.
>
> It happens not that often that someone contributes code. So there's
> not really a process for it.
>
> I would prefer a patch through Bugzilla and a mail on the list
> pointing to this Bugzilla entry. The prefered format is "git diff".
>
> And most important, don't forget to tell me if the patch is on top of
> the freedesktop repository or the gitorious repository.
>
> regards
> Andreas
>
> > Andreas at al:
> >
> > I have a co-worker who would like to make an addition to the
> > project. What is the best way to do this? I read on the website we
> > would submit the patch through Bugzilla. Is this still correct? Or
> > should we send the patch to this email list?
> >
> > Second question- what would be the best way for us to create the
> > patch for you? Use 'git format-patch'? Normal 'diff' command?
> >
> > Thanks for your time.
> >
> > Respectfully,
> > Jay Freyensee
> > UMG
> > (apologize in advance on email syntax; broken collarbone)
> >
------------------------------
Message: 4
Date: Mon, 16 Nov 2009 22:51:30 +0100
From: Andreas Volz <li...@br...>
Subject: Re: [dbus-cplusplus-devel] contributing a submission to the
project...best way?
To: dbu...@li...
Message-ID: <20091116225130.3ce6905f@frodo.mittelerde>
Content-Type: text/plain; charset=US-ASCII
Am Tue, 10 Nov 2009 12:28:19 -0800 schrieb Freyensee, James P:
> A co-worker of mine just submitted bug 25022 that contains our
> addition to the project. We verified the merge (from freedesktop)
> works, at least for the product we are using with it. We did not see
> a category for "dbus-c++" so we filed it under "dbus" but stuck
> "dbuc-c++" in the Title.
I applied some part of the patch. We could discuss about parts I didn't
yet apply (in the lib):
examples:
- op-cp
- op-signal
- most example modifications (I didn't yet look into it to deep)
connection.h/connection.cpp:
extern DXXAPI Dispatcher* default_dispatcher;
...and all changes specific to the change that Connection constructors
have a new parameter Dispatcher* dispatcher.
I've a raw idea what's the reason for it. But could you explain what
was the main idea behind this change.
connection.h/connection.cpp:
set_timeout()/get_timeout() stuff
-> applied
eventloop.cpp:
DefaultMutex::DefaultMutex()
{
pthread_mutex_t recmutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
_mutex = recmutex;
//_mutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
//pthread_mutex_init(&_mutex, NULL);
}
What was the reason of doing this?
The rest of the eventloop integration is applied now.
generate_adaptor.cpp/generate_proxy.cpp/generator_utils.cpp:
What are exactly the reason of these change? Looks for me like some sort
of Async method support. Could you spend some more words here?
regards
Andreas
------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
End of dbus-cplusplus-devel Digest, Vol 16, Issue 5
***************************************************
------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
End of dbus-cplusplus-devel Digest, Vol 16, Issue 6
***************************************************
|
