>
> Problem is in tox the environment seems to be cleaned so neither USERNAME
> or LOGNAME is set.
Ugh, that was where my tests failed too.
I've added today this to the [testenv] section in tox:
setenv =
LOGNAME=<username>
USER=<username>
It runs without errors in python2.7 in the version of txdbus PRIOR to your
changes.
I am not sure if your fix results in false-positive, however. I think we
can just set environment in the tox.ini and avoid doubts.
if unsure what object corresponds to Py3 you can look at the six module
> where some aliases are defined to ensure types are correct between both
> versions.
>
Ah, thank you! I've never tried to write python2-3 compatible programs
before.
Eliza
On Sat, May 30, 2015 at 4:02 AM, <[email protected]> wrote:
> I think maintaining a mockup d-bus implementation might be more work than
> it’s worth, but I might look into it for my own use in a project I’m
> working on.
>
> I had to patch a testcase that failed in Py27 while running tox. In
> test_authentication there’s a function named get_username that’s supposed
> (as far as I can tell) to return the username for the
> user logged in. Problem is in tox the environment seems to be cleaned so
> neither USERNAME or LOGNAME is set.
> I patched this by using getpass.getuser() instead, but I can see as well
> that in the authentication module the getpass import is mocked of with
> another mockup object defined
> in the same test “GetPass”.
>
> While the tests succeed now, is this a false-positive that should not pass
> or is my patch ok?
>
> Regarding the byte string issue, it’s not really an issue. The b’’
> notation in 2.7 returns a string whereas in 3.x it returns a byte object,
> so using it to make sure the
> string is interpreted as a byte-type object in both 2 and 3 is ok.
>
> For reference, if unsure what object corresponds to Py3 you can look at
> the six module where some aliases are defined to ensure types are correct
> between both versions.
>
>
>
> On Thu, May 28, 2015 at 4:47 PM, Tom Cocagne <[email protected]>
> wrote:
>
>> With regard to the tests, I started out with the initial goal of
>> implementing a minimal DBus server in addition to the client that would
>> have *just* enough functionality to support the client-side unit tests. I
>> got it mostly working but then ran out of steam a while back and wound up
>> dropping support for it. Most of the tests pass when pointed at it but
>> there were some hangs in the signaling logic that I never got around to
>> figuring out. The code is still there and it probably wouldn't be overly
>> difficult to resurrect if anyone finds themselves in a bored and slightly
>> masochistic mood one weekend.
>>
>> As to the string vs bytestring issues, that code was donated by another
>> contributor a while back. I've never had a reason to touch Python 3 so I'm
>> still a little in the dark on the nuances involved. You guys almost
>> certainly know better than I how to address these issues. As long as the
>> testing works out, I certainly won't complain about any changes you make in
>> that regard.
>>
>> Tom
>>
>> On Thu, May 28, 2015 at 5:12 AM, Elizaveta Guseva <[email protected]>
>> wrote:
>>
>>> Hello,
>>>
>>> Using tox I’m not getting that import error so try that and verify that
>>>> the issue still exists.
>>>>
>>> I checked with tox, and get only the 3 issues mentioned by you in python
>>> 3.4
>>>
>>> I've also enabled issues on the repository.
>>>
>>>
>>> @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?
>>>>
>>> Sure.
>>>
>>> I have looked into marshaling tests briefly.
>>>
>>> Errors seem to come from difference in bytearray format
>>> Changing strings to bytes make it work for 2.7 and 3.4 pythons.
>>>
>>> There's one more issue of the same nature:
>>> on the line 268 of test_marshal in the function* test_bytearray(self)*
>>>
>>> In the struct.pack*(fm*t, v1, v2 ....) format string *fmt* has
>>> changed meaning of 's':
>>> It used to convert between C-char and Python-string in 2.7
>>> In python 3.4 it convert between C-char and Python-bytes.
>>> It seems to me, the byte mark b was missing in front of dbus signature
>>> on that line.
>>> At least, b stands in front of all other signatures...
>>> I might be wrong.
>>>
>>> I pushed the changes just in case.
>>>
>>> Eliza
>>>
>>>
>>>
>>>
>>> On Thu, May 28, 2015 at 3:36 AM, <[email protected]> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> --
>>> 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.
>
--
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.
