New transfer tool for Linux: HPex

[ramon_ea1gth]

I believe I have some clues about what happens with the connection with a MetaKernel calculator. If I choose in the calculator the decimal separator to be a comma, this is the error reported in the computer terminal when starting a Kermit connection:

Code:

  File "/home/ramros/hpex/hpex-1.0.0/helpers.py", line 92, in checksum_to_hexstr
    return '#' + str(hex(int(checksum))).replace('0x', '').upper() + 'h'
ValueError: invalid literal for int() with base 10: '13036,'

However, choosing a dot as the decimal separator in the calculator, the error report turns into:

Code:

  File "/home/ramros/hpex/hpex-1.0.0/helpers.py", line 92, in checksum_to_hexstr
    return '#' + str(hex(int(checksum))).replace('0x', '').upper() + 'h'
ValueError: invalid literal for int() with base 10: '13036.'

Notice the change from '13036,' to '13036.'
As the MetaKernel calculators have real numbers (type 0) and integers (type 28), MetaKernel machines differentiate them by appending the decimal separator (dot or comma) in the real number. So some numbers/results (type 0) that were output by the HP48 series with no decimal separator now are delivered with it in a MetaKernel machine. Thus, I guess that HPex has to remove this separator in a MetaKernel calculator.

[Edit]:
I forgot to include the results from Thomas Klemm's suggestion, so here they are:

(05-16-2022 11:24 PM)Thomas Klemm Wrote:  In order to analyse the problem you could insert a print statement in line 858 of /home/ramros/hpex/hpex-1.0.0/hpex_gui.py:

Code:

            # each element of each row is the name, size, type, and
            # crc in that order
            print(i)

This might give some insights into the output from Kermit.

So here it is the output of the print command:

Code:


['DibSmith', '6149.5', 'Directory', '13036.']

Good suggestion to support these ideas.