On Wed, 10 Aug 2005 13:23:22 GMT, rumours say that [EMAIL PROTECTED] (Bengt
Richter) might have written:
>BTW, my second post was doing ''.join(chr(int(h[i:i+2],16)) for i in
>xrange(0,16,2))
>to undo the hexlify you had done (I'd forgotten that there's a
>binascii.unhexlify ;-)
And there's als
Calvin Spealman wrote:
>
> Original Poster should send this off to thedailywtf.com
I absolutely agree. This is a terrible programming practice.
--
http://mail.python.org/mailman/listinfo/python-list
On 8/10/05, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2005-08-10, John Machin <[EMAIL PROTECTED]> wrote:
>
> Perhaps the one bit is an exponent -- some kind of floating point
> based format? That matches the doubling of all digits.
> >>>
> >>>That would just be sick. I can't imagine
Thanks again.
Sort of thru me off, but is working perfectly now.
--
http://mail.python.org/mailman/listinfo/python-list
On 2005-08-10, John Machin <[EMAIL PROTECTED]> wrote:
Perhaps the one bit is an exponent -- some kind of floating point
based format? That matches the doubling of all digits.
>>>
>>>That would just be sick. I can't imagine anybody on an 8-bit
>>>CPU using FP for a phone number.
>> >>>
On 2005-08-10, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Tue, 09 Aug 2005 21:50:06 -, Grant Edwards <[EMAIL PROTECTED]> wrote:
>
>>On 2005-08-09, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>>> Grant Edwards wrote:
>Ex #1) 333-
>Hex On disk: 00 00 00 80 6a 6e 49 41
>
>>
On 10 Aug 2005 05:30:37 -0700, [EMAIL PROTECTED] wrote:
>Thanks so much for this. It is exactly what I was looking for.
>
>If I am simply reading the bytes from disk, would I still need to
>convert the these values HEX characters first with Hexlify, or is there
>a more direct route ?
>ie. convert
Thanks so much for this. It is exactly what I was looking for.
If I am simply reading the bytes from disk, would I still need to
convert the these values HEX characters first with Hexlify, or is there
a more direct route ?
ie. convert them to the double float directly from the byte values ?
--
Bengt Richter wrote:
> On Tue, 09 Aug 2005 21:50:06 -, Grant Edwards <[EMAIL PROTECTED]> wrote:
>
>
>>On 2005-08-09, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>>
>>>Grant Edwards wrote:
>>>
>Ex #1) 333-
>Hex On disk: 00 00 00 80 6a 6e 49 41
>
>Ex #2) 666-
>H
On Wed, 10 Aug 2005 03:47:06 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
>On Tue, 09 Aug 2005 21:50:06 -, Grant Edwards <[EMAIL PROTECTED]> wrote:
>
>>On 2005-08-09, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>>> Grant Edwards wrote:
>Ex #1) 333-
>Hex On disk: 00 00 00 80 6
On Tue, 09 Aug 2005 21:50:06 -, Grant Edwards <[EMAIL PROTECTED]> wrote:
>On 2005-08-09, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> Grant Edwards wrote:
Ex #1) 333-
Hex On disk: 00 00 00 80 6a 6e 49 41
Ex #2) 666-
Hex On disk: 00 00 00 80 6a 6e 59 41
>>>
Grant Edwards wrote:
> And I'll guarantee that the difference between 333- and
> 666- has to be more than 1-bit. There's no way that can be
> the correct data unless it's something like an index into a
> different table or a pointer or something along those lines.
Absolutely. I hadn't ev
On 2005-08-09, Christopher Subich <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>> That would just be sick. I can't imagine anybody on an 8-bit
>> CPU using FP for a phone number.
>
> Nobody on an 8-bit CPU would have a FPU, so I'll guarantee that this is
> done using only 8 or 16-bit (probab
Grant Edwards wrote:
> That would just be sick. I can't imagine anybody on an 8-bit
> CPU using FP for a phone number.
Nobody on an 8-bit CPU would have a FPU, so I'll guarantee that this is
done using only 8 or 16-bit (probably 8) integer math.
--
http://mail.python.org/mailman/listinfo/python
On 2005-08-09, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>>>Ex #1) 333-
>>>Hex On disk: 00 00 00 80 6a 6e 49 41
>>>
>>>Ex #2) 666-
>>>Hex On disk: 00 00 00 80 6a 6e 59 41
>>
>> So there's only a 1-bit different between the on-disk
>> representation of 333-
Dejan Rodiger said the following on 9.08.2005 23:28:
> [EMAIL PROTECTED] said the following on 9.08.2005 22:45:
>
>>Yes I double checked as I appreciate any help, but that is what is
>>stored on disk.
>>
>>If it helps, we modified Ex#3. to be 777-777-
>>On disk this is now 00 00 10 87 77 F9 Fc
Grant Edwards wrote:
>>Ex #1) 333-
>>Hex On disk: 00 00 00 80 6a 6e 49 41
>>
>>Ex #2) 666-
>>Hex On disk: 00 00 00 80 6a 6e 59 41
>
> So there's only a 1-bit different between the on-disk
> representation of 333- and 666-.
>
> That sounds pretty unlikely. Are you 100% sure you'
[EMAIL PROTECTED] said the following on 9.08.2005 22:45:
> Yes I double checked as I appreciate any help, but that is what is
> stored on disk.
>
> If it helps, we modified Ex#3. to be 777-777-
> On disk this is now 00 00 10 87 77 F9 Fc 41
>
> All the input fields are filled in this new examp
Yes I double checked as I appreciate any help, but that is what is
stored on disk.
If it helps, we modified Ex#3. to be 777-777-
On disk this is now 00 00 10 87 77 F9 Fc 41
All the input fields are filled in this new example.
--
http://mail.python.org/mailman/listinfo/python-list
On 2005-08-09, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I can posted records as it will take up to much space. But all
> three phone numbers are stored in 8 bytes with null bytes (ie.
> 00) stored in the leading positions (ie. the left hand side)
>
> I do have some more examples;
>
> I have
You are correct, that was a typo.
the second example should end in F441.
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
Dejan Rodiger wrote:
> [EMAIL PROTECTED] said the following on 9.08.2005 19:29:
>
>>Phone 1: 5616864700
>>Hex On Disk: C0DBA8ECF441
>
>
> 5616864700(10)=14ECA8DBC(16)
> 14 EC A8 DB Cleftshift by 4 bits (it will add 0 on last C)
> C0 DB A8 EC 14 00 write bytes from right to left
> C0 DB A8 EC
Dejan Rodiger wrote:
> 8003346488(10)=1DD096038(16)
> 1D D0 96 03 8
> 80 03 96 D0 1D 00
> 80 03 96 d0 fd 41 Add E041
I'm pretty sure that the last full byte is a parity check of some sort.
I still thing that Phone2 (..F1) is a typo and should be 41. Even if
it's not, it could be a more detail
the extension on the files is *.mas but I a pretty sure it is not
relevant. I beleive it used by the application.
I can posted records as it will take up to much space.
But all three phone numbers are stored in 8 bytes with null bytes (ie.
00) stored in the leading positions (ie. the left hand si
[EMAIL PROTECTED] said the following on 9.08.2005 19:29:
> Phone 1: 5616864700
> Hex On Disk: C0DBA8ECF441
5616864700(10)=14ECA8DBC(16)
14 EC A8 DB Cleftshift by 4 bits (it will add 0 on last C)
C0 DB A8 EC 14 00 write bytes from right to left
C0 DB A8 EC F4 41 Add E041
> Phone 1: 8003346488
[EMAIL PROTECTED] said the following on 9.08.2005 19:29:
> We are working on a data file reader and extraction tool for an old
> MS-DOS accounting system dating back to the mid 80's.
Could you tell us what is the extension of those files?
Could you post full 5-10 records (ASCII + HEX)?
--
Dejan
[EMAIL PROTECTED] wrote:
> I am hoping someone can help me solve a bit of a puzzle.
>
> We are working on a data file reader and extraction tool for an old
> MS-DOS accounting system dating back to the mid 80's.
>
> In the data files, the text information is stored in clearly readable
> ASCII tex
I am hoping someone can help me solve a bit of a puzzle.
We are working on a data file reader and extraction tool for an old
MS-DOS accounting system dating back to the mid 80's.
In the data files, the text information is stored in clearly readable
ASCII text, so I am comfortable that this file i
28 matches
Mail list logo
