On 19/10/2006, at 12:02 AM, Lars T. Mikkelsen wrote:
Hi Pieter,
On Wed, Oct 18, 2006 at 12:59:03PM +0200, Pieter Rautenbach wrote:
*******************************************************************
Click here to view our e-mail legal notice:
http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000
*******************************************************************
Oh, silly me! Here goes:
[EMAIL PROTECTED] pymsnt-0.11.2-dev2]$ python src/legacy/msn/
msnp11chl.py
13902169664655191882
My output: 026184bdf82adcc7032c1d99330c683f
Lars'output: 26184bdf82adcc7432c1d99330c683f2
[EMAIL PROTECTED] pymsnt-0.11.2-dev2]$ python src/legacy/msn/
msnp11chl.py
13038318816579321232
My output: b01c13020e374d4fa20abfad6981b7a9
Lars'output: b01c13020e374d4fa20abfad6981b7a9
The first one doesn't match your result, but the second does.
I forgot to mention my platform in my first post:
[EMAIL PROTECTED] pymsnt-0.11.2-dev2]$ uname -a
Linux lutetium.mxit.co.za 2.6.9-34.ELsmp #1 SMP Thu Mar 9 06:23:23
GMT 2006
x86_64 x86_64 x86_64 GNU/Linux
Okay, I think I figured out what's wrong. Apparently struct.unpack has
changed behaviour between Python 2.4 and Python 2.5. Consider the
following two lines of code:
import struct
print type(struct.unpack(">L", "xxxx")[0])
With Python 2.4 this will return "<type 'long'>". With Python 2.5,
however, it returns "<type 'int'>". This becomes a problem in line
58 of
msnp11chl.py, as the hex representation is now missing an L at the
end.
It looks like it's only an issue on 64-bit architectures tough.
I'm not sure if this is actually a bug in Python 2.5. I've made a
quick
patch to workaround the issue, but I'm not sure if it will break
anything else. :-)
Best regards,
Lars
<msnp11chl-long.patch>
Thanks guys. I'll look into this...
---
James
_______________________________________________
py-transports mailing list
[email protected]
http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
