Nabble - Free Desktop - dbus

Re: dbus-string.c problem ?

2009-12-20T00:39:30Z

Em Domingo 20. Dezembro 2009, às 04.38.48, Paul McNary escreveu:
> Hello when trying to run I get the following error:
>
> 18437: assertion failed "additional_length >= 0" file "dbus-string.c" line
> 867 function unknown function D-Bus not compiled with backtrace support so
> unable to print a backtrace EOF in dbus-launch reading address from bus
> daemon

When trying to run what?

> I don't under stand the function unknown function part.

It probably is a result of the missing debug information.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

dbus-string.c problem ?

2009-12-19T19:38:48Z

Hello when trying to run I get the following error:

18437: assertion failed "additional_length >= 0" file "dbus-string.c" line 867 function unknown function
D-Bus not compiled with backtrace support so unable to print a backtrace
EOF in dbus-launch reading address from bus daemon

I don't under stand the function unknown function part.

Thanks for any help

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [Patch] increase dbus_verbose readability

2009-12-18T09:09:47Z

Ralf Habacker schrieb:
> If those functions would be located into a
> specific context related header like dbus-file.h then it would be even
> clearer, which functions are available in the "file related" context.
>
>
I tried to go a step in this directection by placing the small pseudo
"class" DBusPipe into separate files. (The above mentioned dbus-file
stuff was skipped for now because it needs more attention)
It needed some more iterations until it works both on windows and unix
mainly because of required macro location move for DBUS_GNU_PRINTF and
some cryptic DBusPipe forward declarations, which did not allow to be
overriden by the real struct definition. If was required to remove those
DBusPipe forward declarations and to include the dbus-pipe.h header.

I will see if there is additional time to migrate additional pseudo
"classes"

Regards
Ralf

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [Patch] increase dbus_verbose readability

2009-12-17T08:09:12Z

Ralf Habacker schrieb:
> Ralf Habacker schrieb:
>> Hi,
>>
>> Are there any helpfull suggestions for this feature ?
> patch updated - the previous patch contains an unrelated part - sorry
> for confusion.
I just compiled dbus with the patch on linux and got the following error:

dbus-internals.h:86:8: error: __VA_ARGS__ can only appear in the
expansion of a C99 variadic macro

which comes from the following line trying to detect variable args support
#ifdef __VA_ARGS__

Does anyone have an idea how to detect otherwise if the compiler
supports variable argument replacement in macros or can we assume that
any compiler support this ?

Ralf

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [Patch] increase dbus_verbose readability

2009-12-17T03:58:53Z

Tor Lillqvist schrieb:

> Just a related note:
>
>
>> + if (*p == DBUS_DIR_SEPARATOR)
>>
>
> Please, check for both slash and backslash on Windows, they are
> equivalent (at the Win32, and thus certainly C library, level) and
> either can occur for various reasons. I.e., use a
> DBUS_IS_DIR_SEPARATOR() function-type macro instead of
> DBUS_DIR_SEPARATOR. Something like:
>
> #ifdef DBUS_WIN
> #define DBUS_IS_DIR_SEPARATOR(c) ((c) == '\\' || (c) == '/')
> #else
> #define DBUS_IS_DIR_SEPARATOR(c) ((c) == '/')
> #endif
>

which probably should go into dbus-sysdeps.h, where the other path
related functions/macros are located ?

It's often hard to find the correct location and naming convention
because dbus uses internal one big context named _dbus_.
These contexts looks like a namespace or class term leaned on from the
c++ universe or what ever name could be imagined for this kind of grouping

There are some additional contexts like _dbus_file with functions like

_dbus_file_get_content() and dbus_file_exist(),

but there are also

_dbus_make_file_world_readable()
_dbus_create_file_exclusively
_dbus_delete_file

which are - at least from my point of view - related to this dbus_file_
context but are named completly different.

I guess

_dbus_file_make_world_readable()
_dbus_file_create_exclusively()
_dbus_file_delete()

would make it clearer. If those functions would be located into a
specific context related header like dbus-file.h then it would be even
clearer, which functions are available in the "file related" context.

My guess is that these dbus-sysdeps.h stuff was introduced in the -
small size - beginning of this project. Now the dbus project has reached
a size where better approaches (as described above for one topic) would
make the implementation easier to understand.

Any comments ?

Ralf

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [Patch] increase dbus_verbose readability

2009-12-17T02:52:03Z

Just a related note:

> + if (*p == DBUS_DIR_SEPARATOR)

Please, check for both slash and backslash on Windows, they are
equivalent (at the Win32, and thus certainly C library, level) and
either can occur for various reasons. I.e., use a
DBUS_IS_DIR_SEPARATOR() function-type macro instead of
DBUS_DIR_SEPARATOR. Something like:

#ifdef DBUS_WIN
#define DBUS_IS_DIR_SEPARATOR(c) ((c) == '\\' || (c) == '/')
#else
#define DBUS_IS_DIR_SEPARATOR(c) ((c) == '/')
#endif

(Yes, this makes the code a bit more complex when what you would want
to do is something like strchr(s, DBUS_DIR_SEPARATOR).)

(And for file names there is also the multi-byte codepage issue... in
the CJK codepages some characters have as trailing byte a slash or
backslash, so actually one should use multi-byte string functions when
scanning strings looking for directory separators... but let's not get
into that now.)

--tml
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [Patch] increase dbus_verbose readability

2009-12-17T01:15:14Z

Ralf Habacker schrieb:
> Hi,
>
> Are there any helpfull suggestions for this feature ?
patch updated - the previous patch contains an unrelated part - sorry
for confusion.

Ralf

diff --git a/dbus/dbus-internals.c b/dbus/dbus-internals.c
index edf7de6..9d4ef8d 100644
--- a/dbus/dbus-internals.c
+++ b/dbus/dbus-internals.c
@@ -329,6 +329,41 @@ _dbus_verbose_init (void)
}
}

+#ifdef DBUS_WIN
+#define DBUS_DIR_SEPARATOR '\\'
+#else
+#define DBUS_DIR_SEPARATOR '/'
+#endif
+
+/**
+ remove source root from file path
+ the source root is determined by
+*/
+static char *_dbus_file_path_extract_elements_from_tail(const char *file,int level)
+{
+ static int prefix = -1;
+ char *p;
+
+ if (prefix == -1)
+ {
+ char *p = file + strlen(file);
+ int i = 0;
+ prefix = 0;
+ for (;p >= file;p--)
+ {
+ if (*p == DBUS_DIR_SEPARATOR)
+ {
+ if (++i >= level)
+ {
+ prefix = p-file+1;
+ break;
+ }
+ }
+ }
+ }
+ return file+prefix;
+}
+
/**
* Implementation of dbus_is_verbose() macro if built with verbose logging
* enabled.
@@ -350,7 +385,14 @@ _dbus_is_verbose_real (void)
* @param format printf-style format string.
*/
void
+#ifdef __VA_ARGS__
+_dbus_verbose_real (const char *file,
+ const int line,
+ const char *function,
+ const char *format,
+#else
_dbus_verbose_real (const char *format,
+#endif
...)
{
va_list args;
@@ -382,17 +424,24 @@ _dbus_verbose_real (const char *format,
need_pid = TRUE;
else
need_pid = FALSE;
-
+
va_start (args, format);
#ifdef DBUS_USE_OUTPUT_DEBUG_STRING
{
char buf[1024];
strcpy(buf,module_name);
+#ifdef __VA_ARGS__
+ vsprintf (buf+strlen(buf), "%s(%d):%s ",_dbus_file_path_extract_elements_from_tail(file,2),line,function);
+#endif
vsprintf (buf+strlen(buf),format, args);
va_end (args);
OutputDebugString(buf);
}
#else
+#ifdef __VA_ARGS__
+ fprintf (stderr, "%s(%d):%s ",_dbus_file_path_extract_elements_from_tail(file,2),line,function);
+#endif
+
vfprintf (stderr, format, args);
va_end (args);

diff --git a/dbus/dbus-internals.h b/dbus/dbus-internals.h
index 8b5af8d..a79ee20 100644
--- a/dbus/dbus-internals.h
+++ b/dbus/dbus-internals.h
@@ -83,12 +83,18 @@ void _dbus_warn_check_failed (const char *format,

#ifdef DBUS_ENABLE_VERBOSE_MODE

+#ifdef __VA_ARGS__
+void _dbus_verbose_real (const char *file, const int line, const char *function,
+ const char *format,...) _DBUS_GNUC_PRINTF (1, 2);
+# define _dbus_verbose(fmt,...) _dbus_verbose_real( __FILE__,__LINE__,__FUNCTION__,fmt, ## __VA_ARGS__)
+#else
void _dbus_verbose_real (const char *format,
...) _DBUS_GNUC_PRINTF (1, 2);
+# define _dbus_verbose _dbus_verbose_real
+#endif
void _dbus_verbose_reset_real (void);
dbus_bool_t _dbus_is_verbose_real (void);

-# define _dbus_verbose _dbus_verbose_real
# define _dbus_verbose_reset _dbus_verbose_reset_real
# define _dbus_is_verbose _dbus_is_verbose_real
#else

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Patch] increase dbus_verbose readability

2009-12-17T00:55:04Z

Hi,

_dbus_verbose is currently the prefered way to print debug information.
With the recent implementation it is sometime hard to determine the
exact source location. There is still the way to add the function name
manually, but this need additional manual efforts to keep the name in
sync with reality.

Modern compilers have build in support for determine source code
location like file name, line number and function names, which could be
used to reduce the required effort in this area.

The appended patch extends dbus_verbose by adding filename, line number
and function name to the output line like shown below

old:
5616: Loaded value 256 for limit max_names_per_connection
5616: Skipping non-.conf file basic.d

new:
5616: bus\config-parser.c(2564):bus_config_parser_content Loaded value
256 for limit max_names_per_connection
5616: bus\config-parser.c(3116):all_are_equiv Skipping non-.conf file
basic.d

bus\config-parser.c - filename
(3116) - line number
all_are_equiv - function name

Are there any helpfull suggestions for this feature ?

Regards
Ralf

diff --git a/bus/dispatch.c b/bus/dispatch.c
index f769a44..ef534ac 100644
--- a/bus/dispatch.c
+++ b/bus/dispatch.c
@@ -4536,11 +4536,13 @@ bus_dispatch_test_conf (const DBusString *test_data_dir,
if (!check_add_match_all (context, baz))
_dbus_assert_not_reached ("AddMatch message failed");

+#ifndef DBUS_WIN
if (!check_get_connection_unix_user (context, baz))
_dbus_assert_not_reached ("GetConnectionUnixUser message failed");

if (!check_get_connection_unix_process_id (context, baz))
_dbus_assert_not_reached ("GetConnectionUnixProcessID message failed");
+#endif

if (!check_list_services (context, baz))
_dbus_assert_not_reached ("ListActivatableNames message failed");
diff --git a/bus/test-main.c b/bus/test-main.c
diff --git a/cmake/CMakeLists.txt b/cmake/CMakeLists.txt
diff --git a/cmake/config.h.cmake b/cmake/config.h.cmake
diff --git a/dbus/dbus-internals.c b/dbus/dbus-internals.c
index edf7de6..9d4ef8d 100644
--- a/dbus/dbus-internals.c
+++ b/dbus/dbus-internals.c
@@ -329,6 +329,41 @@ _dbus_verbose_init (void)
}
}

+#ifdef DBUS_WIN
+#define DBUS_DIR_SEPARATOR '\\'
+#else
+#define DBUS_DIR_SEPARATOR '/'
+#endif
+
+/**
+ remove source root from file path
+ the source root is determined by
+*/
+static char *_dbus_file_path_extract_elements_from_tail(const char *file,int level)
+{
+ static int prefix = -1;
+ char *p;
+
+ if (prefix == -1)
+ {
+ char *p = file + strlen(file);
+ int i = 0;
+ prefix = 0;
+ for (;p >= file;p--)
+ {
+ if (*p == DBUS_DIR_SEPARATOR)
+ {
+ if (++i >= level)
+ {
+ prefix = p-file+1;
+ break;
+ }
+ }
+ }
+ }
+ return file+prefix;
+}
+
/**
* Implementation of dbus_is_verbose() macro if built with verbose logging
* enabled.
@@ -350,7 +385,14 @@ _dbus_is_verbose_real (void)
* @param format printf-style format string.
*/
void
+#ifdef __VA_ARGS__
+_dbus_verbose_real (const char *file,
+ const int line,
+ const char *function,
+ const char *format,
+#else
_dbus_verbose_real (const char *format,
+#endif
...)
{
va_list args;
@@ -382,17 +424,24 @@ _dbus_verbose_real (const char *format,
need_pid = TRUE;
else
need_pid = FALSE;
-
+
va_start (args, format);
#ifdef DBUS_USE_OUTPUT_DEBUG_STRING
{
char buf[1024];
strcpy(buf,module_name);
+#ifdef __VA_ARGS__
+ vsprintf (buf+strlen(buf), "%s(%d):%s ",_dbus_file_path_extract_elements_from_tail(file,2),line,function);
+#endif
vsprintf (buf+strlen(buf),format, args);
va_end (args);
OutputDebugString(buf);
}
#else
+#ifdef __VA_ARGS__
+ fprintf (stderr, "%s(%d):%s ",_dbus_file_path_extract_elements_from_tail(file,2),line,function);
+#endif
+
vfprintf (stderr, format, args);
va_end (args);

diff --git a/dbus/dbus-internals.h b/dbus/dbus-internals.h
index 8b5af8d..a79ee20 100644
--- a/dbus/dbus-internals.h
+++ b/dbus/dbus-internals.h
@@ -83,12 +83,18 @@ void _dbus_warn_check_failed (const char *format,

#ifdef DBUS_ENABLE_VERBOSE_MODE

+#ifdef __VA_ARGS__
+void _dbus_verbose_real (const char *file, const int line, const char *function,
+ const char *format,...) _DBUS_GNUC_PRINTF (1, 2);
+# define _dbus_verbose(fmt,...) _dbus_verbose_real( __FILE__,__LINE__,__FUNCTION__,fmt, ## __VA_ARGS__)
+#else
void _dbus_verbose_real (const char *format,
...) _DBUS_GNUC_PRINTF (1, 2);
+# define _dbus_verbose _dbus_verbose_real
+#endif
void _dbus_verbose_reset_real (void);
dbus_bool_t _dbus_is_verbose_real (void);

-# define _dbus_verbose _dbus_verbose_real
# define _dbus_verbose_reset _dbus_verbose_reset_real
# define _dbus_is_verbose _dbus_is_verbose_real
#else
diff --git a/dbus/dbus-mainloop.c b/dbus/dbus-mainloop.c
diff --git a/dbus/dbus-sysdeps-win.c b/dbus/dbus-sysdeps-win.c

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: 60 secs logout delay when running emacs: Why ?

2009-12-16T14:30:30Z

Em Quarta-feira 16. Dezembro 2009, às 21.21.52, Gerd Bavendiek escreveu:

> Hi,
>
> running Xubuntu Karmic and using Emacs, I'm always wondering about a
> significant delay after clicking logout. Basically after having
> clicked logout 60 secs nothing happens until the session is finally
> closed.
>
> If I first close Emacs and then click logout, the session is closed
> immediately. So the delay really seems to be linked to emacs. There is
> no logout dialog AFAIK. Running emacs without my init-files did not
> change anything.
>
> This delay is a bit irritating, but most of the time not a real
> problem. It is possible to shorten the delay by "clicking
> around". Typically switching to the workspace emacs is running in
> makes the session terminate immediately. Occasionally clicking around
> does not terminate the session and I have to wait.
>
> So I just wanted to know which component causes the delay.
>
> I straced emacs. After logout he ist happily running for about 60
> secs. Then he gets SIGTERM 4 times.
>
> I ran dbus-monitor > file and got an empty file (output buffering). I
> compiled dbus 1.3.1 and ran it like so:
>
> ./dbus-monitor | perl -ne 'print scalar localtime(), $_' > file
>
> Now I do see a lot of activities after clicking logout, then exactly
> 60 secs nothing and another bulk of messages. To be honest: This is
> beyond my skills, I cannot interpret this output (285 lines).
>
> I really would appreciate if somebody could push me into the right
> direction. Is it a bug, a misconfiguration or works a designed ?
> emacs or xfce4-session ?

I think you're dumping the wrong protocol.

X logout is announced to the applications via XSM, not via D-Bus.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

60 secs logout delay when running emacs: Why ?

2009-12-16T12:21:52Z

Hi,

running Xubuntu Karmic and using Emacs, I'm always wondering about a
significant delay after clicking logout. Basically after having
clicked logout 60 secs nothing happens until the session is finally
closed.

If I first close Emacs and then click logout, the session is closed
immediately. So the delay really seems to be linked to emacs. There is
no logout dialog AFAIK. Running emacs without my init-files did not
change anything.

This delay is a bit irritating, but most of the time not a real
problem. It is possible to shorten the delay by "clicking
around". Typically switching to the workspace emacs is running in
makes the session terminate immediately. Occasionally clicking around
does not terminate the session and I have to wait.

So I just wanted to know which component causes the delay.

I straced emacs. After logout he ist happily running for about 60
secs. Then he gets SIGTERM 4 times.

I ran dbus-monitor > file and got an empty file (output buffering). I
compiled dbus 1.3.1 and ran it like so:

./dbus-monitor | perl -ne 'print scalar localtime(), $_' > file

Now I do see a lot of activities after clicking logout, then exactly
60 secs nothing and another bulk of messages. To be honest: This is
beyond my skills, I cannot interpret this output (285 lines).

I really would appreciate if somebody could push me into the right
direction. Is it a bug, a misconfiguration or works a designed ?
emacs or xfce4-session ?

Thanks

Gerd

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: Dbus asynchronous

2009-12-16T02:32:07Z

On Wed, Dec 16, 2009 at 9:24 AM, Vivek Anand <vivek@...> wrote:

> I am working on an application which is completely asynchronous. I want
> to add dbus support to it. But I dont want to block between dbus method
> calls.
>
> Is there any way to bring out the dbus connection fd, so that I can add
> it my current select loop, or is there any other dbus implimentation
> which is completely asynchronous?

Any chance you could just use the glib mainloop as your select loop?
That's the way dbus is usually used, so you would at least avoid
creating your own private problem set ;-).

--
Ville M. Vainio
http://tinyurl.com/vainio
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: Dbus asynchronous

2009-12-16T01:42:23Z

Le mercredi 16 décembre 2009 à 12:54 +0530, Vivek Anand a écrit :
> Is there any way to bring out the dbus connection fd, so that I can add
> it my current select loop, or is there any other dbus implimentation
> which is completely asynchronous?

I made an implementation of D-Bus in ocaml [1]. It uses cooperative
threads [2], so it is completely asynchronous.

[1] https://forge.ocamlcore.org/projects/obus/
[2] http://ocsigen.org/lwt/

--
Jérémie

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: Dbus asynchronous

2009-12-16T00:22:32Z

Em Quarta-feira 16. Dezembro 2009, às 08.24.44, Vivek Anand escreveu:
> Hello all,
> I am working on an application which is completely asynchronous. I want
> to add dbus support to it. But I dont want to block between dbus method
> calls.
>
> Is there any way to bring out the dbus connection fd, so that I can add
> it my current select loop, or is there any other dbus implimentation
> which is completely asynchronous?

There are methods for that in DBusConnection, plus the DBusWatcher and
DBusTimeout structures.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

Dbus asynchronous

2009-12-15T23:24:44Z

Hello all,
I am working on an application which is completely asynchronous. I want
to add dbus support to it. But I dont want to block between dbus method
calls.

Is there any way to bring out the dbus connection fd, so that I can add
it my current select loop, or is there any other dbus implimentation
which is completely asynchronous?

--
Vivek Anand
HiPro IT Solutions
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

RE: [PATCH] use montonic clock instead of gettimeofday

2009-12-15T09:48:27Z

> IMHO you should update the documentation for _dbus_get_current_time or,
> even better, rename it to reflect the new semantics. It does not return
> 'current' time as in gettimeofday any more, because the meaning of
> absolute time values is now unspecified.

Agreed.

> That part of the patch certainly looks broken. The
> pthread_condattr_setclock() would need to come after
> pthread_condattr_init().
> And further below the new end_time.tv_nsec calculation is completely off
> (by 3 to 6 orders of magnitude).

Yes, you're right on these.

I'm not going to resubmit that part of the patch, since the correct version has already been committed (ae24bb35e2ee3ecde990f55852982b573754ec43). :)

The first part of the patch was submitted as a bug here: https://bugs.freedesktop.org/show_bug.cgi?id=25624

Tom
________________________________________
From: Joerg.Barfurth@... [Joerg.Barfurth@...] On Behalf Of Joerg Barfurth [jub@...]
Sent: Tuesday, December 15, 2009 12:55 AM
To: Tom Hughes
Cc: dbus@...
Subject: Re: [PATCH] use montonic clock instead of gettimeofday

Tom Hughes schrieb:
> Greetings,
>

Greetings. Just noticed this patch.

> Attached is a patch to use the monotonic clock instead of gettimeofday()
> in _dbus_get_current_time(), which prevents issues when
> _dbus_get_current_time() is used to calculate timeouts and the system
> time changes (e.g., in _dbus_connection_block_pending_call()).
>

IMHO you should update the documentation for _dbus_get_current_time or,
even better, rename it to reflect the new semantics. It does not return
'current' time as in gettimeofday any more, because the meaning of
absolute time values is now unspecified.

If this function is used in DBus for anything other than elapsed time or
timeout calculations, the old version would need to be kept as well.

> It also contains a patch for pthread_cond_timedwait to use the monotonic
> clock, but this appears to have already been fixed, so you can ignore
> that part of the patch.
>

That part of the patch certainly looks broken. The
pthread_condattr_setclock() would need to come after
pthread_condattr_init().

And further below the new end_time.tv_nsec calculation is completely off
(by 3 to 6 orders of magnitude).

Regards

- Jörg B
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [PATCH] use montonic clock instead of gettimeofday

2009-12-15T01:36:43Z

Em Terça-feira 15 Dezembro 2009, às 09:55:51, Joerg Barfurth escreveu:

> Tom Hughes schrieb:
> > Greetings,
>
> Greetings. Just noticed this patch.
>
> > Attached is a patch to use the monotonic clock instead of gettimeofday()
> > in _dbus_get_current_time(), which prevents issues when
> > _dbus_get_current_time() is used to calculate timeouts and the system
> > time changes (e.g., in _dbus_connection_block_pending_call()).
>
> IMHO you should update the documentation for _dbus_get_current_time or,
> even better, rename it to reflect the new semantics. It does not return
> 'current' time as in gettimeofday any more, because the meaning of
> absolute time values is now unspecified.
>
> If this function is used in DBus for anything other than elapsed time or
> timeout calculations, the old version would need to be kept as well.

The bug report for this issue is Bug 25624.

> > It also contains a patch for pthread_cond_timedwait to use the monotonic
> > clock, but this appears to have already been fixed, so you can ignore
> > that part of the patch.
>
> That part of the patch certainly looks broken. The
> pthread_condattr_setclock() would need to come after
> pthread_condattr_init().
>
> And further below the new end_time.tv_nsec calculation is completely off
> (by 3 to 6 orders of magnitude).

Apparently that part of the patch was already applied in current 1.3 codebase.
Can you check there if it looks ok?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

Re: [PATCH] use montonic clock instead of gettimeofday

2009-12-15T00:55:51Z

Tom Hughes schrieb:
> Greetings,
>

Greetings. Just noticed this patch.

> Attached is a patch to use the monotonic clock instead of gettimeofday()
> in _dbus_get_current_time(), which prevents issues when
> _dbus_get_current_time() is used to calculate timeouts and the system
> time changes (e.g., in _dbus_connection_block_pending_call()).
>

IMHO you should update the documentation for _dbus_get_current_time or,
even better, rename it to reflect the new semantics. It does not return
'current' time as in gettimeofday any more, because the meaning of
absolute time values is now unspecified.

If this function is used in DBus for anything other than elapsed time or
timeout calculations, the old version would need to be kept as well.

> It also contains a patch for pthread_cond_timedwait to use the monotonic
> clock, but this appears to have already been fixed, so you can ignore
> that part of the patch.
>

That part of the patch certainly looks broken. The
pthread_condattr_setclock() would need to come after
pthread_condattr_init().

And further below the new end_time.tv_nsec calculation is completely off
(by 3 to 6 orders of magnitude).

Regards

- Jörg B
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: Message did not receive a reply (timeout by message bus)

2009-12-12T12:28:19Z

> ** (openvrml-player:19497): CRITICAL **: Browser creation failed:
Message did not receive a reply
> (timeout by message bus)
> **
> ** ERROR:(../../src/openvrml-player/curlbrowserhost.cpp:347):void
> openvrml_player_curl_browser_host_load_url(OpenvrmlPlayerCurlBrowserHost*,
const char*):
> assertion failed: (host->priv->browser)
> Aborted

I'm having the same problem...
Does anyone know what can be done?

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[PATCH] dbus-daemon-launch-helper: fix build with libxml

2009-12-11T12:05:49Z

From 8032e967a4684e93ab25067b1b4344dbd8d0526d Mon Sep 17 00:00:00 2001
From: Peter Korsgaard <jacmet@...>
Date: Sun, 31 May 2009 09:37:49 +0200

dbus-daemon-launch-helper links with the trival config parser, which
doesn't provide bus_config_parser_check_doctype(), like the big parser does.
The libxml loader unfortunately wants to call it, so this breaks the build.

Fix it by including a dummy bus_config_parser_check_doctype() in the trivial
config parser.

Signed-off-by: Peter Korsgaard <jacmet@...>
Signed-off-by: Marc Kleine-Budde <mkl@...>
Signed-off-by: Robert Schwebel <r.schwebel@...>
---
bus/config-parser-trivial.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/bus/config-parser-trivial.c b/bus/config-parser-trivial.c
index 98d554e..a936371 100644
--- a/bus/config-parser-trivial.c
+++ b/bus/config-parser-trivial.c
@@ -310,6 +310,14 @@ bus_config_parser_get_service_dirs (BusConfigParser *parser)
return &parser->service_dirs;
}

+dbus_bool_t
+bus_config_parser_check_doctype (BusConfigParser *parser,
+ const char *doctype,
+ DBusError *error)
+{
+ return TRUE;
+}
+
#ifdef DBUS_BUILD_TESTS
#include <stdio.h>
#include "test.h"
--
1.6.3.1

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: interface dbus method call

2009-12-10T23:25:31Z

Em Sexta-feira 11. Dezembro 2009, às 00.16.14, jaikumar Ganesh escreveu:

> Correct me if I am reading this wrong:
>
> reply = dbus_connection_send_with_reply(conn, msg,
> &call,
> timeout_ms);
> if (reply == TRUE) {
> dbus_pending_call_set_notify(call,
> dbus_func_args_async_callback,
> pending,
> NULL);
> }
>
> is what I am using - so I assume the callback will be called when the
> function call times out or is done.
> In my case, since timeout_ms = -1, the default timeout value of 25
> secs is being used and then the callback returns after the timeout.
>
> As the interface is not up, I would assume the callback to come back
> immediately with a failure.

Nothing happens immediately, except for trying to send a message while you're
disconnected.

The message needs to be sent to the daemon, that will send to the remote
program, which will in turn say that the interface isn't up by replying with
an error, which the daemon will relay back to you.

So your callback will be called. Just wait for it to be called.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

Re: interface dbus method call

2009-12-10T15:16:14Z

Correct me if I am reading this wrong:

reply = dbus_connection_send_with_reply(conn, msg,
&call,
timeout_ms);
if (reply == TRUE) {
dbus_pending_call_set_notify(call,
dbus_func_args_async_callback,
pending,
NULL);
}

is what I am using - so I assume the callback will be called when the
function call times out or is done.
In my case, since timeout_ms = -1, the default timeout value of 25
secs is being used and then the callback returns after the timeout.

As the interface is not up, I would assume the callback to come back
immediately with a failure.

Thanks

On Thu, Dec 10, 2009 at 3:01 PM, Thiago Macieira <thiago@...> wrote:

> Em Quinta-feira 10. Dezembro 2009, às 19.38.15, jaikumar Ganesh escreveu:
>> Unfortunately, I don't see that happening. I am using
>> dbus_connection_send_with_reply and I get back a pending callback. The
>> interface is not up at this point, and I was expecting the call to
>> fail. Anyway the interface comes up later but the call just hangs.
>
> It will fail. But it needs to be sent to the server first.
>
> You need to wait for the pending call to be finished.
>
>>
>> If the interface is up and running, before I make the call, everything is
>> good.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Senior Product Manager - Nokia, Qt Development Frameworks
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> dbus mailing list
> dbus@...
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
>

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: [PATCH] use montonic clock instead of gettimeofday

2009-12-10T15:05:31Z

Em Quinta-feira 10. Dezembro 2009, às 18.27.23, Tom Hughes escreveu:

> Greetings,
>
> Attached is a patch to use the monotonic clock instead of
> gettimeofday() in _dbus_get_current_time(), which prevents issues when
> _dbus_get_current_time() is used to calculate timeouts and the system
> time changes (e.g., in _dbus_connection_block_pending_call()).
>
> It also contains a patch for pthread_cond_timedwait to use the
> monotonic clock, but this appears to have already been fixed, so you
> can ignore that part of the patch.
>
> It's based off dbus version 1.1.20, but should apply to top of trunk.

Thanks Tom, patch looks good.

Can you add it to bugzilla so we don't lose track of it? Please submit it as
the output of git format-patch, so we can credit you properly with the change.

PS: my autoconf/automake are very rusty, but don't you need to get the library
to link to librt?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

Re: interface dbus method call

2009-12-10T15:01:29Z

Em Quinta-feira 10. Dezembro 2009, às 19.38.15, jaikumar Ganesh escreveu:
> Unfortunately, I don't see that happening. I am using
> dbus_connection_send_with_reply and I get back a pending callback. The
> interface is not up at this point, and I was expecting the call to
> fail. Anyway the interface comes up later but the call just hangs.

It will fail. But it needs to be sent to the server first.

You need to wait for the pending call to be finished.

>
> If the interface is up and running, before I make the call, everything is
> good.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

Re: interface dbus method call

2009-12-10T10:38:15Z

Unfortunately, I don't see that happening. I am using
dbus_connection_send_with_reply and I get back a pending callback. The
interface is not up at this point, and I was expecting the call to
fail. Anyway the interface comes up later but the call just hangs.

If the interface is up and running, before I make the call, everything is good.

Has anyone else seen this ?

Thanks
Jaikumar

On Thu, Dec 10, 2009 at 3:34 AM, Thiago Macieira <thiago@...> wrote:

> Em Quinta-feira 10 Dezembro 2009, às 09:31:28, jaikumar Ganesh escreveu:
>> Hello folks:
>> Is there a way for me to check if someone has registered an
>> interface on whom I will be invoking a method call using:
>>
>> dbus_message_new_method_call ( const char * destination,
>> const char * path,
>> const char * interface,
>> const char * method
>>
>> I basically want to abort if the interface is not registered.
>
> The way to find out is to make the call. If it returns with error, then it
> didn't exist (or the path didn't or the destination didn't).
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Senior Product Manager - Nokia, Qt Development Frameworks
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> dbus mailing list
> dbus@...
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
>

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[PATCH] use montonic clock instead of gettimeofday

2009-12-10T09:27:23Z

Greetings,

Attached is a patch to use the monotonic clock instead of
gettimeofday() in _dbus_get_current_time(), which prevents issues when
_dbus_get_current_time() is used to calculate timeouts and the system
time changes (e.g., in _dbus_connection_block_pending_call()).

It also contains a patch for pthread_cond_timedwait to use the
monotonic clock, but this appears to have already been fixed, so you
can ignore that part of the patch.

It's based off dbus version 1.1.20, but should apply to top of trunk.

Tom

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

dbus-monotonic-clock.patch (4K) Download Attachment

Re: dbus-glib bindings on WinXP with mingw compiler

2009-12-10T07:51:43Z

In http://tml.pp.fi/dbus-glib.diff you will find some patches I used
when building dbus-glib for Windows a month or so ago.

--tml
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

dbus-glib bindings on WinXP with mingw compiler

2009-12-10T07:21:02Z

I tried to compile dbus-glib-0.82 on winxp using the mingw/msys tools using the standard
configure, make, make install steps. I used dbus-mingw-1.2.4-1-lib and dbus-mingw-1.2.4-1-bin
as the dbus implementation from the sourceforge.net page with an custom dbus-1.pc for pkg-config.
While configure runs through without problems compilations fails with:
make[4]: Entering directory `/home/root/mingw-additional/dbus-glib-0.82/test/core'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../dbus -I../.. -I../../dbus -Ic:/mingw/include/dbus-1.0 -Ic:/mingw/lib/dbus-1.0/include -mms-bitfields -Ic:/mingw/include/glib-2.0 -Ic:/mingw/lib/glib-2.0/include -DDBUS_COMPILATION -I/mingw/include -I/usr/local/include -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -fno-strict-aliasing -MT test-profile.o -MD -MP -MF .deps/test-profile.Tpo -c -o test-profile.o test-profile.c
test-profile.c:32:24: error: sys/socket.h: No such file or directory
test-profile.c:33:20: error: sys/un.h: No such file or directory
test-profile.c:34:24: error: netinet/in.h: No such file or directory
test-profile.c: In function 'plain_sockets_new_client_watch':
test-profile.c:757: error: storage size of 'addr' isn't known
test-profile.c:771: warning: implicit declaration of function 'accept'
test-profile.c:771: warning: nested extern declaration of 'accept'
test-profile.c:757: warning: unused variable 'addr'
test-profile.c: In function 'plain_sockets_init_server':
test-profile.c:801: error: storage size of 'addr' isn't known
test-profile.c:820: warning: implicit declaration of function 'socket'
test-profile.c:820: warning: nested extern declaration of 'socket'
test-profile.c:820: error: 'PF_UNIX' undeclared (first use in this function)
test-profile.c:820: error: (Each undeclared identifier is reported only once
test-profile.c:820: error: for each function it appears in.)
test-profile.c:820: error: 'SOCK_STREAM' undeclared (first use in this function)
test-profile.c:830: error: 'AF_UNIX' undeclared (first use in this function)
test-profile.c:844: warning: implicit declaration of function 'S_ISSOCK'
test-profile.c:844: warning: nested extern declaration of 'S_ISSOCK'
test-profile.c:851: warning: implicit declaration of function 'bind'
test-profile.c:851: warning: nested extern declaration of 'bind'
test-profile.c:858: warning: implicit declaration of function 'listen'
test-profile.c:858: warning: nested extern declaration of 'listen'
test-profile.c:801: warning: unused variable 'addr'
test-profile.c: In function 'plain_sockets_thread_func':
test-profile.c:940: error: storage size of 'addr' isn't known
test-profile.c:947: error: 'PF_UNIX' undeclared (first use in this function)
test-profile.c:947: error: 'SOCK_STREAM' undeclared (first use in this function)
test-profile.c:957: error: 'AF_UNIX' undeclared (first use in this function)
test-profile.c:970: warning: implicit declaration of function 'connect'
test-profile.c:970: warning: nested extern declaration of 'connect'
test-profile.c:940: warning: unused variable 'addr'

Without knowing exactly what i am speaking about for me it seems that the files in test/core are not
windows compatible. Just out of curiosity a made a patch against the makefile in that folder to not compile
anything. This is the patch:
$ cat Makefile-dbus-glib-0.82-test-core.patch
--- Makefile.orig 2009-12-09 09:46:10 +0000
+++ Makefile 2009-12-09 09:46:47 +0000
@@ -445,8 +445,9 @@
test-profile.c

test_profile_LDADD = $(DBUS_GLIB_THREADS_LIBS) $(top_builddir)/dbus/libdbus-glib-1.la
-all: $(BUILT_SOURCES)
- $(MAKE) $(AM_MAKEFLAGS) all-am
+#all: $(BUILT_SOURCES)
+# $(MAKE) $(AM_MAKEFLAGS) all-am
+all:

.SUFFIXES:
.SUFFIXES: .c .lo .o .obj
@@ -751,8 +752,9 @@
$(MAKE) $(AM_MAKEFLAGS) check-am
all-am: Makefile $(PROGRAMS)
installdirs:
-install: $(BUILT_SOURCES)
- $(MAKE) $(AM_MAKEFLAGS) install-am
+#install: $(BUILT_SOURCES)
+# $(MAKE) $(AM_MAKEFLAGS) install-am
+install:
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am

After this modification i was quite surprised because make and make install were successful.
It seems as if dbus-glib code is portable enough but not the tests.
I used the following to compile and install dbus-glib:
./configure --disable-tests --disable-doxygen-docs || exit
cd test/core
patch -p0 -i ../../../Makefile-dbus-glib-0.82-test-core.patch || exit
cd ../../
make || exit
make install || exit
I hope that this information is useful for somebody else.

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: interface dbus method call

2009-12-10T03:34:55Z

Em Quinta-feira 10 Dezembro 2009, às 09:31:28, jaikumar Ganesh escreveu:

> Hello folks:
> Is there a way for me to check if someone has registered an
> interface on whom I will be invoking a method call using:
>
> dbus_message_new_method_call ( const char * destination,
> const char * path,
> const char * interface,
> const char * method
>
> I basically want to abort if the interface is not registered.

The way to find out is to make the call. If it returns with error, then it
didn't exist (or the path didn't or the destination didn't).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (197 bytes) Download Attachment

interface dbus method call

2009-12-10T00:31:28Z

Hello folks:
Is there a way for me to check if someone has registered an
interface on whom I will be invoking a method call using:

dbus_message_new_method_call ( const char * destination,
const char * path,
const char * interface,
const char * method

I basically want to abort if the interface is not registered.

Thanks
Jaikumar
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

New dbus-java release

2009-12-06T03:51:25Z

I've released dbus-java 2.7. Tarballs here:

http://dbus.freedesktop.org/releases/dbus-java/dbus-java-2.7.tar.gz

Changelog:

Version 2.7:

- Fix bug in disconnected signal/exception handling (Spotted by
Serkan Kaba <serkan_kaba -at- yahoo -dot- com>)
- Fix bug in empty signals (Spotted by Daniel Wagner <Daniel -dot-
Wagner -at- bmw-carit -dot- de>)
- Fix bug in maps containing complex types (Spotted by Tim Court <tim
-dot- court -at- venture3systems -dot- com>)
- Fix signal handling bug in DBusDaemon (Spotted by Markus Gaebelein
<Markus -dot- Gaebelein -at- fiducia -dot- de>)
- Make MessageReader/Writer use Buffered streams to try and improve
performance
- Support reading session bus address from file in $HOME
- Fix TCP cookie timestamp problems (Report/fix from Johannes Felten
<johannesfelten -at- googlemail -dot- com>)
- Add handleError() method to callbacks (breaks backwards source
compatibility)

Matt
--
www.matthew.ath.cx
D-Bus Java

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (852 bytes) Download Attachment

RE: Java D-Bus API: Handling errors with callWithCallback()

2009-12-02T11:18:26Z

> Currently, no, no and no, having looked at the code (-:

> Sensible options would seem to be:

> 1. add public void handleError(DBusException e); as a method on
> CallbackHandler, thus requiring everyone to implement it in their
> handlers

> ... actually, I'm not sure what else would be a sensible suggestion. I
> should certainly fix it up so that it discards callbacks when errors
> occur.

I would certainly we interested in such changes. It might help the Java binding compare more favorably with the Python binding which supports these features (and more) but is generally limited to the Linux world due to its heavy dependency on GLib, D-Bus library, etc... It (the Python binding) is just too difficult to build for Windows.

I'm currently *trying* to use your library to develop test applications that run on a Windows host and talk via TCP/IP to an embedded target running D-Bus with anonymous authentication. It does work but for now it appears I'll have to settle for synchronous communication between the host (Windows PC) and the embedded target if I want to be able to receive errors. An asynchronous communication pattern would be preferred. It seems like the Java binding is 95% there . . .

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

RE: dbus daemon auto start on system reboot

2009-12-01T21:07:08Z

/etc/init.d/dbus

./dbus start

./dbus stop

This Dbus script will run on system start up, you can modify the path in this file as per your installation.

Nirav

From: dbus-bounces@... [mailto:dbus-bounces@...] On Behalf Of luying pan
Sent: Wednesday, December 02, 2009 2:42 AM
To: dbus@...
Subject: dbus daemon auto start on system reboot

Does anyone know which configuration file controls which dbus-daemon to start automatically on system restart? I have two dbus versions installed. The one installed under /usr/bin can be auto-started on system startup, but the one installed under /usr/local/bin can not be.

I'm running fedora 11. Not too familiar with system startup scripts. Help is appreciated.

Luying

Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Re: Java D-Bus API: Handling errors with callWithCallback()

2009-12-01T15:51:37Z

On Tue Dec 01 12:35, Schmottlach, Glenn wrote:

> I am (attempting) to write a Java D-Bus client that uses
> AbstractConnection.callWithCallback() to asynchronously issue requests
> to a D-Bus service. This reason I am using this method versus
> AbstractConnection.callMethodAsync() is that I want to be notified
> (via the callback) when the reply is returned rather than wait (or
> poll) for the response. I have successfully used this method to
> make requests to services and received a response via the callback
> (e.g. it works as advertised). What I want to understand is how to
> handle D-Bus error messages returned instead of a response to a
> request. If I was issuing a blocking call through the remote object's
> interface I could put a try/catch block around the request and "catch"
> the error message. With callWithCallback() method there does not
> appear to be a mechanism to report back any errors. Likewise, there
> does not appear to be a mechanism to either cancel the request or
> specify a timeout on the request. So, to summarize, these are my
> questions:

Sorry, yes, I should do this. You've asked a much harder question though
(-;

Firstly, you're probably the first person to actually use this API, I
added it since it seemed like it might be useful.

> 1) How do I detect errors using callWithCallback()?
> 2) Can I specify a timeout to wait for a response with callWithCallback()?
> 3) Can I cancel a request issued with callWithCallback()?

Currently, no, no and no, having looked at the code (-:

Sensible options would seem to be:

1. add public void handleError(DBusException e); as a method on
CallbackHandler, thus requiring everyone to implement it in their
handlers

... actually, I'm not sure what else would be a sensible suggestion. I
should certainly fix it up so that it discards callbacks when errors
occur.

Matt

--
www.matthew.ath.cx
D-Bus Java

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (852 bytes) Download Attachment

dbus daemon auto start on system reboot

2009-12-01T13:12:20Z

Re: DBus Java method call?

2009-12-01T12:21:08Z

Schmottlach, Glenn wrote:

> Yes, AbstractConnection is an abstract but it's not an Interface (e.g. it provides a partial implementation). If you have a DBusConnection instance available you can call 'callMethodAsync' on that (since it inherits from AbstractConnection).
>
>
> -----Original Message-----
> From: dbus-bounces@... [mailto:dbus-bounces@...] On Behalf Of Arigead
> Sent: Tuesday, December 01, 2009 2:24 PM
> To: Schmottlach, Glenn
> Cc: dbus@...
> Subject: Re: DBus Java method call?
>
> Schmottlach, Glenn wrote:
>> You can find it (callMethodAsync) in the AbstractConnection class.
>>
>>
>> -----Original Message-----
>> From: dbus-bounces@... [mailto:dbus-bounces@...] On Behalf Of Arigead
>> Sent: Tuesday, December 01, 2009 1:14 PM
>> To: dbus@...
>> Subject: DBus Java method call?
>>
>> Hello all,
>> I've been looking whatever info I can find on Java DBus such as the
>> API [1] and the High Level Documentation mentioned in the DBus Java Page
>> [2].
>>
>> Basically that High Level Documentation gives an example of an
>> asynchronous call as:
>>
>> DBusAsyncReply<Boolean> stuffreply =
>> conn.callMethodAsync(remoteObject, "methodname", arg1, arg2);
>>
>> But I can't find that "callMethodAsync" method in the API Documentation
>> [1]. I simply want to call a Dbus method defined by RhythmBox and ignore
>> any response. Actually I don't think it has any response.
>>
>> Could anybody suggest the API methods for Java DBus which achieve this?
>>
>> Thanks a million for any help
>>
>>
>> [1] http://dbus.freedesktop.org/doc/dbus-java/api/
>> [2] http://dbus.freedesktop.org/doc/dbus-java/
>> _______________________________________________
>> dbus mailing list
>> dbus@...
>> http://lists.freedesktop.org/mailman/listinfo/dbus
>>
>
>
> Thanks for the mighty quick response and sorry for being stupid with
> this DBus Java, but that AbstractConnection is Abstract. I can't see
> where I get an AbstractConnection from.
>
> If I ever get this to work I hope there'll be time to write up a basic
> document so that other people can do some simple Java DBus. Maybe there
> is a clear document that shows the steps involved in using this API but
> I've not found it as yet. Maybe a Tutorial or something of the like.
>
> Thanks for helping anyhow, still a struggle ;-)
> _______________________________________________

My Homer moment of the day. Thanks for that ;-)

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus