[Bitpim-devel] Re: [Bitpim-user] 0.7-test10 on Sanyo SCP-5500

[Roger Binns]

OK, the problem was that the last p_sanyonewer.py that I checked in
ended up being a null file.

Any idea how that happened? (I am also curious as to why you get a
CRC error since such checking should happen before

Roger, can you do a new build? It will keep the noise level on the
lists from being to high for the next two weeks.

Steven, can you redo the Mac build?

Can we do something reduce the problems of out of date p_*.py files, or
even elinate them from the CVS?

The reason they are in CVS is so that we can get back exactly an
earlier release. Whenever you have "built" files, and don't save
them, it can get quite difficult knowing what went on. Also
rebuilding them automatically could also result in unintentional
differences. Arguably I am being overly cautious, but I wanted
to be in a situation where I know for sure that the Mac, Linux and
Windows builds are all using exactly the same code.

I had also hoped that having the releases available for day to
bitpim-devel folks would mean they get some double checking.

Roger

[Stephen Wood]

Post by Roger Binns

OK, the problem was that the last p_sanyonewer.py that I checked in
ended up being a null file.

Any idea how that happened? (I am also curious as to why you get a
CRC error since such checking should happen before

It might have been that I was checking in the file at a time when my
wireless connection was flaking in and out.

The packet coming back is 0x13 followed by 16 bytes of the request
packet followed by the checksum. The 0x13 is in the checksum. The
code, interprets the 0x13 as junk, strips it, then checks the checksum.
I'll catalog the various error responses (Other bad packets return the
brew "Y" followed by a fragment of the request packet) and see if I can
improve the Sanyo sendpbcommand to give more meaningful errors.

Do the LG phones do anything similar in response to packets they don't
recognize? Why do the brew exceptions work? Do brew errors not echo
back a fragment of the packet, thus not fooling
"d=date.find(firsttwo)".

Post by Roger Binns

Roger, can you do a new build? It will keep the noise level on the
lists from being to high for the next two weeks.

Steven, can you redo the Mac build?

Can we do something reduce the problems of out of date p_*.py files, or
even elinate them from the CVS?

The reason they are in CVS is so that we can get back exactly an
earlier release. Whenever you have "built" files, and don't save
them, it can get quite difficult knowing what went on. Also
rebuilding them automatically could also result in unintentional
differences. Arguably I am being overly cautious, but I wanted
to be in a situation where I know for sure that the Mac, Linux and
Windows builds are all using exactly the same code.

How about a check in makedist that the p_*.py files are not out of data
(and not null) that aborts if anything is wrong. I'll code it if you'll
use it.

Post by Roger Binns
I had also hoped that having the releases available for day to
bitpim-devel folks would mean they get some double checking.

Not to mention some single checking! I'll do that next time.

Stephen