-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compiler warning in `dbus2#make-vtable' #5
Comments
The problem is mentioned here: https://bugs.call-cc.org/ticket/850
|
Ok, after some research here is what I have found. Please correct me if I'm wrong.
The vtable in the argument to So much for what It seems like libdbus has 3 levels of difficulty/complexity/flexibility for getting messages from the message queue.
When using either Right now the dbus egg uses We could move to one of the more complex methods of handling messages, but for the moment the dbus egg seems to work fine as far as I can tell, and I don't see a downside to the dispatching being handled completely in scheme. I'm only aware of mowedline using it however, so it is possible of course that I just don't know about it. Also, if we do move to one of the more complex methods, I don't think that |
On the somewhat broader issue of how should dbus-egg's main loop work, an issue that I ran into with mowedline is detailed here: retroj/mowedline#22 flood of dbus messages bogs down mowedline The gist is that if we use
|
Without rewriting the entire egg to use DBusWatch (complicated and uncertain), we may be able to get the equivalent of |
Opened issue #6 to discuss the question of handling all waiting messages. In this ticket we can just decide what to do about the original vtable issue. I think that we should remove the vtable and associated code for now, until such time as we decide to rewrite the egg to use DBusWatch instead of |
`dbus_connection_register_object_path` is part of a different api for interacting with DBus than the one this egg is using. VTables are not needed for the way this egg gets messages from DBus, namely `dbus_connection_pop_message`. The bindings here are also incorrect and produced a compiler warning: Warning: in toplevel procedure `dbus2#make-vtable': (dbus2.scm:842) in procedure call to `dbus2#vtable-message_function-set!', expected argument #2 of type `(or boolean pointer locative)' but was given an argument of type `(procedure fn (* * *) fixnum)' The simplest thing is to remove this code until such time as we decide to rewrite the egg to use another method (like DBusWatch) to handle messages. This problem is also described here: https://bugs.call-cc.org/ticket/850 Resolves issue #5.
Done |
The text was updated successfully, but these errors were encountered: