<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> I started work on some for a research project last year. You can download them at <a href="https://coderanger.net/svn/school/2007/fall/spacefortress/trunk/dbus-lisp/">https://coderanger.net/svn/school/2007/fall/spacefortress/trunk/dbus-lisp/</a>. You will need CFFI and closer-mop, but both are available via asdf-install. Look at the test* scripts to see examples.<o:p></o:p> <o:p> </o:p> --Noah<o:p></o:p> <o:p> </o:p> <div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'> From: dbus-bounces@lists.freedesktop.org [mailto:dbus-bounces@lists.freedesktop.org] On Behalf Of Gustavo Sent: Wednesday, May 28, 2008 10:11 AM To: DBus Lista de Discussão Subject: Common-Lisp bindings<o:p></o:p> </div> <o:p> </o:p> Hello, everyone, I program in Common-Lisp and there is no binding to this library, so I decided to create one! I've already started to create bindings for the library with some Lisp abstractions, and when I finish I will create a wrapper to make these bindings look just like it was a built-in Common-Lisp library! But there are somethings I'd like to talk about before starting this second step. First, I would like not to deal with addresses and to give the user the possibility to disconnect and reconnect, so it seems that the right choice is use dbus_bus_get_private and setting dbus_bus_set_exit_on_disconnect(conn, 0), right? I am asking because the documentation says that the get_private should be avoided because multiple connections are slow but I probably won't use more than one connection at the same time, so I guess it has no problems to use this function... Second, dbus supports many types, but Common-Lisp has much more! Common-Lisp also supports optional and endless parameters for functions. So these values: - hash-tables with compose keys (like lists or so) - (heterogeneous) lists (which could be confusing with also heterogeneous arrays) - symbols and keywords (both are similar enough to be colapsed to the same type in a protocol like this one) - object instances and structures (same as before) - limitless integers - rationals - complex numbers - functions - pathnames (for portability issues) (perhaps other things that I don't remember) I was thinking that a good idea was to distingüish the result of the method call org.freedesktop.DBus.Introspection.Instrospect for other common-lisps clients (or whoever requests throw DBus this distinct introspection) and for other regular programs. So, for instance, when sending a list, an array to some regular program it would be transformed into an array before the transmition, while, for common-lisp clients, a list would be sent as '(av)' while an array would be sent as 'av'. A rational could have the signature '(ii)' and a complex '((vv))' (since a complex accepts two rationals, two integers or two floats). Endless integers could be sent as strings or arrays but with different notations than regular strings and arrays. Is sending diferent introspections and method returns to different clients ok or does this violate some rule of the protocol? Or maybe this is not a good practice? Another idea would be to always transmit the same instrospection and let program deal with it (a program in C, for instance, would be obligated to transform, by hand, '(av) into 'av', which is ok to me (C is already confuse anyway) but C or Java programmers might not like to deal with this resolution. Third, a protocol extension idea: there could be a header option informing something like "oh, whenever you see '(av)' you can transform it into 'av' if you like" (an array of struct of two type signatures), to deal with the previous issue in a more portable way. Perhaps another field telling which internal data representation protocol or whatever this message is "encoded" in. What do you think? This could be a not good idea since the protocol supports so many types just to not to have to deals with these issues. Well, this is it. Sorry for the very long message. Gustavo<o:p></o:p> </div> </body> </html>