Hi, 2009/4/1 Mark Lagendijk <mar...@marksspeelhoekje.nl>: > Since I hated the adds and looks of msn messenger, I switched to aMSN a few > years ago. I have been an enthusiastic user since. Around a half year ago I > saw the blogpost of one of the developers about aMSN 2. I thought it would > be fun to start contributing, but since there was only a 'getting started' > guide for Linux I lost interest and forgot all about it.
It is nice to know that some people prefer aMSN to the official client! > A month ago I > searched for a Windows guide again, but it still wasn't there. I then > decided to make this guide myself, afterall it couldn't be any harder than > getting the amsn2 code, installing python and maybe a few other things. > These 'few other things' turned out to be quite a few (see my post on the > forums: http://www.amsn-project.net/forums/viewtopic.php?p=37552#37552 ), so > it took me around a day to get it working. Well I think it is an average time when you have to figure out "few other things" to get started, hopefully your experience will shorten this time for other users! > It was then that I found out that I couldn't log in. I spoke with a few > developpers on the irc channel, and said that I would fix the bug myself. > > There turned out to be 2 bugs: > The first bug is that the socket object has the status 'OPEN', but in fact > isn't open at all. This means there is a bug in the sock class (or one of > its super classes) of the 'gnet' module of pymsn. I spend some time trying > to analyse this bug. I found out the following: > > The actual opening of the socket returns the 'EWOULDBLOCK' error code (line > 99 of 'iochannel.py': err = self._transport.connect_ex((host, port) ). > Might this be the problem? In the code this error is handled the same as no > error: the status is set to 'OPEN'. > The bug doesn't occur when opening 'test.py' from pymsn. Has this anything > to do with some sort of threading? (I am new to python and don't know if it > has threading, or how it uses it). I do not know why it works in test.py and > not in aMSN2, but I do know that the socket object it self is responsible > for making sure that it is really open when it says it is. > When I put a 'sleep' of 1 second in the 'post open' function the bug didn't > occur anymore. First of all I must say that I know close to nothing about the internals of PyMSN so I'll give you some general advice on how to find an answer on your own: first of all I'd try to find out what an EWOULDBLOCK error code means. Then you could dive into the amsn2 code to see how it handles connecting and how it is different from test.py. This has 2 advantages: first you familiarize with the code, and second you could find a way to reproduce this bug in a simple test (for instance by modifying test.py). If you achieve that, you can have a better understanding of the issue and could figure out if it's a PyMSN bug or an amsn2 one. As for threading, Python has its own threading implementation, but it is an internal rewrite of threads and so it basically doesn't work with C extensions. We are using Gobject's implementation for threading, you may want to check that out to get a better understanding. > The second bug occurs in both aMSN 2 and test.py. > > Only one package (2048 bytes) from the soapresponse is read. After this the > socket closes. Should the socket stay open? Or should it close, but first > pass the data it received? > > When I also use a workaround for this (changing the 2048 bytes to 8000, so > the first package contains the whole response) I am able to log in and chat. > > Is there anyone (who knows the ins and outs of sockets), who can fix these > bugs, or point me in the right direction? Sockets on windows are quite different from sockets on *nix so there could be a difference in behaviour in Python too. You should check with the documentation about the sockets and see if you can find something about this. If on *nix systems logging in works it means that we are receiving the whole data, hence the logic should be there. You'd have to find where and why it stops on windows (it would also help to find out if it's something that happens on every windows box or it's just on yours). Workarounds like yours are fine, but a full understanding of the issue would be advisable: it leads to better solutions. I hope I could help you a little on your way to find your own answers ;) Hopefully there is someone who knows better than me and will help you further. -- Stéphane ------------------------------------------------------------------------------ _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
