Youness Alaoui wrote:
2009/4/2 Mark Lagendijk <mar...@marksspeelhoekje.nl
<mailto:mar...@marksspeelhoekje.nl>>
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
I think part of your message was lost :)
Yes, it's frustrating but that's also why we code! because it's also
fun and we love challenges and it's very rewarding once you figure it
out! :) With experience you end up understanding all that stuff! A few
years ago I would have answered you ":o"
Indeed a part of my message dissapeared. I didn't say that fixing bugs
is frustrating, I said that it is frustrating if you don't know wether
you are fixing a problem or fighting its symptoms ;) .
> 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.
Hehe, yeah, actually the socket is closed on both windows and linux,
but linux just waits for you to finish the last chunk of data before
telling you it was closed! :)
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.
And thanks to you especially for taking the time to look into this
problem and fix it! :)
I fixed the bugs now and pushed the patches to my branch
(http://github.com/MarkL/amsn2/commits/master). Can someone review my
code? And how do I get it into the main branch after it is reviewed?
Cya,
Mark
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
<mailto:Amsn-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/amsn-deve
------------------------------------------------------------------------------
_______________________________________________
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-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
