Yes I completely agree with you, the only thing according to me that is worse than a bad code style is an inconsistent code style.
@Eliza: I would like to get started with fixing the unit tests so that we can start working on the interface. If that’s okay with you? @Tom: I was thinking about setting up a Travis worker for our fork to CI our work. Have you tried this before? I realize the entire test suite might not be able to be tested since it depends on a d-bus connection, but I believe the parts that can be tested should be tested. On Wed, May 27, 2015 at 8:38 PM, Tom Cocagne <[email protected]> wrote: > The existing codebase was written in adherence to the Twisted coding > standard in case there was ever a call to merge it into the Twisted > mainline. Personally, I abhor their coding standard but I think consistency > with the surrounding codebase is generally worth the pain. I'm not > interested in draconian adherence to the standard, especially since it > seems unlikely to be merged at this point, but I'd appreciate it if the new > code looked similar to the surrounding code in order to avoid jarring and > potentially confusing differences for future developers. Make sense? > Tom > On Wed, May 27, 2015 at 2:57 AM, <[email protected]> wrote: >> Hi Tom, thank you for your interest in participating in this project! >> Of the top of my head there’s really nothing that needs explaining, the >> code is well documented and structured in a logical fashion. >> >> Would you prefer us to keep the coding style consistent across the project? >> I noticed my coding style differs quite heavily from yours, I believe >> however that a “guest” of a project should adapt to the already defined >> style guidelines so I would have no trouble doing just that. >> >> — >> Sent from Mailbox <https://www.dropbox.com/mailbox> >> >> >> On Tue, May 26, 2015 at 7:44 PM, Tom Cocagne <[email protected]> >> wrote: >> >>> Pontus & Eliza, >>> >>> Please consider me a resource for your efforts. I have little development >>> time available and I wrote txdbus quite a while back but I should at least >>> be able to answer some questions and serve as a sounding board for design >>> and implementation ideas. Good luck! >>> >>> Tom Cocagne >>> >>> On Tuesday, May 26, 2015 at 2:07:32 AM UTC-5, Pontus Karlsson wrote: >>>> >>>> How are you running the tests? Using tox I’m not getting that import >>>> error so try that and verify that the issue still exists. >>>> >>>> Could you enable issues on the repository and start an initial branch >>>> for the abstraction? >>>> >>>> I suggest we keep a branch for the abstraction and when that’s done >>>> we’ll start with the asyncio branch. >>>> >>>> I’ve added a Gitter room as well for general talks regarding how to >>>> proceed, unless you prefer keeping those discussions in this mailing list? >>>> >>>> — >>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>> >>>> >>>> On Tue, May 26, 2015 at 6:34 AM, Elizaveta Guseva <[email protected]> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I've added you as collaborator to my fork. >>>>> >>>>> So for planing and dividing the work I suggest we start of by mapping >>>>>> the work needed to be done and start creating issues on the repository. >>>>>> >>>>> >>>>> OK. That sounds like a plan. >>>>> Last time I worked together with a collaborator. I kept a plan in the >>>>> Wiki of gitHub in order to remember what was the last step and who is >>>>> responsible for which task. >>>>> I don't know if you'd like to use it for coordination. >>>>> https://github.com/gelisa/txdbus/wiki/Plan >>>>> >>>>> I also keep some notes there too. Mainly for myself to keep track of >>>>> things. You can disregard them >>>>> >>>>> My vacation doesn’t start until July really but I do have some spare >>>>>> time on the evenings on which I will work on this. >>>>>> >>>>> That's fine. >>>>> >>>>> The first thing I noticed was that three tests fails on Python 3.4, >>>>>> these seems to be related to string -> bytes differences in the socket >>>>>> implementation which needs to be taken care of first. >>>>>> >>>>> >>>>> Ugh, I run the tests too and saw them. I am going to look into it. >>>>> Did you have issues with import UNIXServerEndpoint/UNIXClientEndpoint >>>>> in Python 3.4? >>>>> It's looks similar to the endpoints, which can be imported in the >>>>> source file of Twisted 15.2.1. Which puzzles me. >>>>> >>>>> Eliza >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, May 25, 2015 at 2:59 AM, <[email protected]> wrote: >>>>> >>>>>> Actually I just remembered twisted can interact with the stdlib >>>>>> logging library as well through >>>>>> `twisted.python.log.PythonLoggingObserver`. >>>>>> >>>>>> So I would change it to using `logging` and in the twisted interface >>>>>> implementation use that. >>>>>> >>>>>> That leaves us with twisted specific code only in: >>>>>> * protocol.py >>>>>> * client.py >>>>>> * object.py >>>>>> * endpoints.py >>>>>> >>>>>> And also the tests needs a bit of abstraction as well, preferably by >>>>>> testing the D-Bus protocol implementation by itself. >>>>>> >>>>>> — >>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>>> >>>>>> >>>>>> On Mon, May 25, 2015 at 8:41 AM, [email protected] < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I forked the project yesterday (github.com/wolfhechel/txdbus) and >>>>>>> had another look at it. >>>>>>> >>>>>>> The first thing I noticed was that three tests fails on Python 3.4, >>>>>>> these seems to be related to string -> bytes differences in the socket >>>>>>> implementation which needs to be taken care of first. >>>>>>> >>>>>>> Six is already a requirement so I would probably use that in order to >>>>>>> normalise the output from the protocols. >>>>>>> >>>>>>> Second step would be to separate all Twisted related code into its >>>>>>> own interfaces and place that code in its own package. >>>>>>> >>>>>>> From those interfaces I would create the abstraction and then create >>>>>>> the asyncio implementation on top of that. >>>>>>> >>>>>>> As for the logging, two approaches came to mind: >>>>>>> 1. Initialize logging alongside the event loop abstraction and pass >>>>>>> the log object to all involved classes. >>>>>>> 2. Setup a global logging object in txdbus.log and upon initalization >>>>>>> setup the appropriate logging facility (default to stdlib logging). >>>>>>> >>>>>>> I would prefer alternative number 1 since IMHO global objects with >>>>>>> common names (such as logger, log, logging) tend to collide with a lot >>>>>>> of >>>>>>> other packages and increase chances of circular import dependencies. >>>>>>> >>>>>>> Since this is really your project, do you wish to start your own fork >>>>>>> so that the main code is held in your account? Otherwise I’ll just give >>>>>>> you >>>>>>> write permission in the fork I’ve already done. >>>>>>> >>>>>>> My vacation doesn’t start until July really but I do have some spare >>>>>>> time on the evenings on which I will work on this. >>>>>>> >>>>>>> So for planing and dividing the work I suggest we start of by mapping >>>>>>> the work needed to be done and start creating issues on the repository. >>>>>>> >>>>>>> — >>>>>>> Sent from Mailbox <https://www.dropbox.com/mailbox> >>>>>>> >>>>>>> >>>>>>> On Sun, May 24, 2015 at 11:33 PM, Elizaveta Guseva <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Ultimately it is your choice, but it sounds like there is interest >>>>>>>>> in >>>>>>>>> this project from the txdbus community, which never hurt a project's >>>>>>>>> chances of success :) >>>>>>>> >>>>>>>> >>>>>>>> Awesome. For me, with my primary scientific programming experience, >>>>>>>> help is never bad =) >>>>>>>> >>>>>>>> OK, I'll start with planning. Will keep you updated. >>>>>>>> >>>>>>>> *Pontus,* >>>>>>>> >>>>>>>> I will start figuring out how to abstract the event loop. >>>>>>>> Do you have any specific plan of action in mind? >>>>>>>> >>>>>>>> With regards, to your plans of participation... >>>>>>>> I don't have much of the collaborative coding experience. >>>>>>>> I am not sure what would be the best way of work organization. >>>>>>>> >>>>>>>> Eliza >>>>>>>> >>>>>>>> >>>>>>>> On Sun, May 24, 2015 at 4:57 PM, Tycho Andersen <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Sat, May 23, 2015 at 09:42:21PM -0400, Elizaveta Guseva wrote: >>>>>>>>> > Hi, >>>>>>>>> > >>>>>>>>> > *Pontus,* >>>>>>>>> > >>>>>>>>> > As I understood from the discussion you mentioned, the author of >>>>>>>>> txbus >>>>>>>>> > cogane wants to keep one code base in order to wait for kdbus >>>>>>>>> merge. >>>>>>>>> > >>>>>>>>> > I think it's not compatible with asyncio, because asyncio isn't >>>>>>>>> supported >>>>>>>>> > in 2.7. >>>>>>>>> >>>>>>>>> asyncio is supported in 2.7 (and <3.3), just not as an stdlib >>>>>>>>> module, >>>>>>>>> so I don't think this is a big factor for us, as we already require >>>>>>>>> users to install it (qtile's event loop is asyncio based no matter >>>>>>>>> which version of python you're running). >>>>>>>>> >>>>>>>>> > Besides that as I saw from code txdbus relies not only on twisted >>>>>>>>> event >>>>>>>>> > loop but also on logger for example. I don't know how it would be >>>>>>>>> possible >>>>>>>>> > to separate twisted and asyncio in that framework without fork, >>>>>>>>> to be. >>>>>>>>> > >>>>>>>>> > I'm also not sure if we should worry about kdbus anytime soon, >>>>>>>>> judging from >>>>>>>>> > the heated discussion about merge into kernel. Maybe I am wrong. >>>>>>>>> > >>>>>>>>> > *Tycho,* >>>>>>>>> > >>>>>>>>> > Where do you think is better to start from txdbus or python-dbus? >>>>>>>>> > >>>>>>>>> > Pontus listed files in txdbus which rely on Twisted. >>>>>>>>> > >>>>>>>>> > As for python-dbus, it's: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > - *bus.py -- calls for abstract async from connection.py* >>>>>>>>> > - _compat.py -- None >>>>>>>>> > - *connection.py -- has abstract async function* >>>>>>>>> > - *_dbus.py -- asks for abstract loop* >>>>>>>>> > - *decorators.py -- calls for abstract async* >>>>>>>>> > - exceptions.py -- None >>>>>>>>> > - *_expat_introspect_parser.py -- None* >>>>>>>>> > - >>>>>>>>> > *gi_service.py -- uses gobjects * >>>>>>>>> > - >>>>>>>>> > *glib.py -- glib.. * >>>>>>>>> > - gobject_service.py -- depricated >>>>>>>>> > - lowlevel.py -- None >>>>>>>>> > - *mainloop -- import from glib bindings* >>>>>>>>> > - *proxies.py -- uses connections' abstract async* >>>>>>>>> > - *server.py **-- asks for abstract loop* >>>>>>>>> > - *service.py -- calls for abstract async* >>>>>>>>> > - types.py -- None >>>>>>>>> > >>>>>>>>> > To me it seems python-dbus hid its gobject dependencies pretty >>>>>>>>> well and it >>>>>>>>> > might be rather easy to add asyncio without touching most of the >>>>>>>>> code. >>>>>>>>> >>>>>>>>> It sounds to me like you might get some help doing it in txdbus, >>>>>>>>> whereas you wouldn't doing it in dbus-python, which is a benefit. >>>>>>>>> >>>>>>>>> A pure python implementation also causes less of a problem with >>>>>>>>> distribution, although again I'm not sure this is a big concern for >>>>>>>>> us >>>>>>>>> since the majority of our users are Linux with a handful of OpenBSD >>>>>>>>> folks. >>>>>>>>> >>>>>>>>> Ultimately it is your choice, but it sounds like there is interest >>>>>>>>> in >>>>>>>>> this project from the txdbus community, which never hurt a project's >>>>>>>>> chances of success :) >>>>>>>>> >>>>>>>>> Tycho >>>>>>>>> >>>>>>>>> > Eliza >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On Sat, May 23, 2015 at 6:54 AM, <[email protected]> wrote: >>>>>>>>> > >>>>>>>>> > > I’ve mentioned this on an issue in txdbus >>>>>>>>> > > https://github.com/cocagne/txdbus/issues/11 and the author had >>>>>>>>> some >>>>>>>>> > > pretty good points on implementing a twisted/asyncio abstraction >>>>>>>>> > > in the txdbus library. >>>>>>>>> > > >>>>>>>>> > > I would be willing to contribute to this as well if the >>>>>>>>> decision is taken >>>>>>>>> > > to simply work on top of txdbus. >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > On Wed, May 20, 2015 at 5:01 AM, Elizaveta Guseva < >>>>>>>>> [email protected]> >>>>>>>>> > > wrote: >>>>>>>>> > > >>>>>>>>> > >> Hello Pontus, >>>>>>>>> > >> >>>>>>>>> > >> Oh, cool! Thanks a lot for your recommendation! >>>>>>>>> > >> I will definitely look into it. >>>>>>>>> > >> >>>>>>>>> > >> Eliza >>>>>>>>> > >> >>>>>>>>> > >> On Tue, May 19, 2015 at 7:47 AM, Pontus Karlsson < >>>>>>>>> > >> [email protected]> wrote: >>>>>>>>> > >> >>>>>>>>> > >>> Not sure on how far you've gotten on researching this, but as >>>>>>>>> the model >>>>>>>>> > >>> of asyncio is heavily inspired by the Twisted structure >>>>>>>>> > >>> I would recommend trying to port txdbus >>>>>>>>> > >>> <https://github.com/cocagne/txdbus> to asyncio. >>>>>>>>> > >>> >>>>>>>>> > >>> I was actually looking into doing this a month back and >>>>>>>>> started to map >>>>>>>>> > >>> the code structure and looking into what needs to be altered: >>>>>>>>> > >>> >>>>>>>>> > >>> - *authentication.py* - Zope interfaces, twisted logger >>>>>>>>> > >>> - *bus.py* - twisted logger and Factory? >>>>>>>>> > >>> - *client.py* - Heavy twisted usage >>>>>>>>> > >>> - *endpoints.py* - Heavy twisted usage >>>>>>>>> > >>> - error.py - No Twisted API usage >>>>>>>>> > >>> - interface.py - No Twisted API usage >>>>>>>>> > >>> - introspection.py - No Twisted API usage >>>>>>>>> > >>> - marshal.py - No Twisted API usage >>>>>>>>> > >>> - message.py - No Twisted API usage >>>>>>>>> > >>> - *objects.py* - Zope interfaces, twisted defer >>>>>>>>> > >>> - *protocol.py* - Zope interfaces, heavy twisted usage >>>>>>>>> > >>> - *router.py* - Twisted log >>>>>>>>> > >>> >>>>>>>>> > >>> My recommended approach here is to fork it and abstract the >>>>>>>>> event loop >>>>>>>>> > >>> to work with both Twisted and asyncio. >>>>>>>>> > >>> >>>>>>>>> > >>> Den måndag 4 maj 2015 kl. 22:54:20 UTC+2 skrev Eliza Guseva: >>>>>>>>> > >>>> >>>>>>>>> > >>>> Hello all, >>>>>>>>> > >>>> >>>>>>>>> > >>>> First. Thanks a lot for choosing me as a student for your >>>>>>>>> project!! >>>>>>>>> > >>>> >>>>>>>>> > >>>> As an international student in USA, I'm having some >>>>>>>>> challenges with >>>>>>>>> > >>>> bureaucratic system in my University. >>>>>>>>> > >>>> It starts taking too long at the moment. So I'd better not >>>>>>>>> wait even >>>>>>>>> > >>>> longer and start communication now. >>>>>>>>> > >>>> I have to warn: there might be issues with the system, but >>>>>>>>> I'm trying >>>>>>>>> > >>>> hard to get it work. >>>>>>>>> > >>>> >>>>>>>>> > >>>> On the brighter topic:) >>>>>>>>> > >>>> As I understand it's time to read the documentation now. >>>>>>>>> > >>>> Could you recommend me the reading, which suits the best for >>>>>>>>> the >>>>>>>>> > >>>> purposes of the project? >>>>>>>>> > >>>> What source codes do you think, I should look into to get a >>>>>>>>> better >>>>>>>>> > >>>> understanding? >>>>>>>>> > >>>> I will be asking questions, in the progress. >>>>>>>>> > >>>> >>>>>>>>> > >>>> Thanks a lot! >>>>>>>>> > >>>> >>>>>>>>> > >>> -- >>>>>>>>> > >>> You received this message because you are subscribed to the >>>>>>>>> Google >>>>>>>>> > >>> Groups "qtile-dev" group. >>>>>>>>> > >>> To unsubscribe from this group and stop receiving emails from >>>>>>>>> it, send >>>>>>>>> > >>> an email to [email protected]. >>>>>>>>> > >>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> > >>> >>>>>>>>> > >> >>>>>>>>> > >> -- >>>>>>>>> > >> You received this message because you are subscribed to a >>>>>>>>> topic in the >>>>>>>>> > >> Google Groups "qtile-dev" group. >>>>>>>>> > >> To unsubscribe from this topic, visit >>>>>>>>> > >> >>>>>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe >>>>>>>>> . >>>>>>>>> > >> To unsubscribe from this group and all its topics, send an >>>>>>>>> email to >>>>>>>>> > >> [email protected]. >>>>>>>>> > >> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> > >> >>>>>>>>> > > >>>>>>>>> > > -- >>>>>>>>> > > You received this message because you are subscribed to the >>>>>>>>> Google Groups >>>>>>>>> > > "qtile-dev" group. >>>>>>>>> > > To unsubscribe from this group and stop receiving emails from >>>>>>>>> it, send an >>>>>>>>> > > email to [email protected]. >>>>>>>>> > > For more options, visit https://groups.google.com/d/optout. >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > You received this message because you are subscribed to the >>>>>>>>> Google Groups "qtile-dev" group. >>>>>>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "qtile-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "qtile-dev" group. >>>>>>>> To unsubscribe from this topic, visit >>>>>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>> [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "qtile-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "qtile-dev" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "qtile-dev" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "qtile-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the Google > Groups "qtile-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qtile-dev/eica8sXohwI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "qtile-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
