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

[Stephen W. <sa...@us...>]

On Tue, 2004-05-11 at 19:24, Roger Binns wrote:
> Stephen Wood wrote:
> > 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)".   

> 
> > 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.

>  
> 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