Youness Alaoui wrote:
2009/4/1 Stéphane Bisinger <stephane.bisin...@gmail.com
<mailto:stephane.bisin...@gmail.com>>
Hi,
Hello Mark! Welcome to the mailing list! :)
2009/4/1 Mark Lagendijk <mar...@marksspeelhoekje.nl
<mailto: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.
Good advice, but I did that allready. The problem was I got stuck and
didn't know if I was fixing the symptoms or the problem itself.
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.
I will check it out when I have the time.
Well, EWOULDBLOCK is easy, it's because the socket is in
'non-blocking' mode, which means when you do a 'connect' or 'send' or
'recv' it will not block until the operation is completed.. the error
EWstablished, it woulOULDBLOCK means exactly what it says, it means
that the operation WOULD BLOCK if the socket was not non-blocking.. in
other words, if you do a 'connect', the error EWOULDBLOCK means "there
was no error, but the connection has not yet been ed block if you
wanted it to finish connecting, so just wait and ask me later if i
finished connecting" which basically translates to "the socket is not
yet OPEN, I will notify you when it actually does become OPEN". So the
state of the socket should go into a 'CONNECTING' state before going
into OPEN state and listen to the socket events to figure out when it
becomes OPEN (usually a 'writable' event means that the connection has
been completed). The sleep 1 is what makes the difference, you force
it to wait until the TCP connection finishes being set up!
That's what I thought. I wasn't sure though and it is frustrating to try
to fix something when you have
About threading I don't know and I don't think so.. look at
amsn2/protocol/protocol.tcl and compare it with test.py, but I don't
think there is much difference.. I think the only difference is maybe
that test.py is slower for some reason by doing some processing, so by
the time it finishes, the socket was already done connecting.
O
> 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).
This also seems like a simple issue!
Actually the server sends you the response then closes the socket..
I'm guessing that on linux you get a 'readable' followed by a 'closed'
event.. but on windows you get the 'closed' event as soon as it
happens.. so what pymsn does is that when it gets the 'closed' event,
it closes everything and thinks it's done.. the solution would be to
do something like :
if event = 'closed':
if socket.data_is_available():
buffer += socket.read_all_remaining_data()
process_close()
(this is of course pseudo code)
When your socket is closed, just make pymsn read whatever the system
stored in its buffer before closing the socket locally, so you don't
miss anything! This should fix it!
Actually I did do exactly this at some time, but then I thought: "if the
socket doesn't close on Linux, it shouldn't close on Windows" and I
concluded that I was fixing a symtom instead of the problem itself. So I
will only have to do that fix again.
Workarounds like yours are fine, but a full understanding of the issue
would be advisable: it leads to better solutions.
Actually, I disagree.. workarounds are fine for TESTING, but I would
REALLY like aMSN2 to be as clean as possible, no hacks anywhere! And I
know that Ali Sabil (original pymsn author) wrote the whole pymsn
library with exactly this idea in mind, he did a lot of engineering to
make sure there would be no hacks anywhere in the code, so trying to
fix the thing correctly is the best solution... I think my tips above
should help you enough in fixing this!
I agree, I never meant the workarounds as fixes, just as a means to find
the problem.
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.
Thanks Stephane, I hope both our answers were helpful for him!
Thank you from me too. You gave good advice on how to get at the bottom
of those bugs. I did allready do what you suggested, though (except the
part about threading), but you couldn't know that since I didn't say so ;).
Anyways, Mark, I don't know if I already took the time to thank you
for what you're doing! I hope you best of luck and thanks for
contributing! :)
KaKaRoTo
Thanks! And thanks for your tips. Now I know where the problems ly and
how I can fix them.
Mark
--
Stéphane
------------------------------------------------------------------------------
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
<mailto:Amsn-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/amsn-devel
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-deve
------------------------------------------------------------------------------
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
