printing hex

[WilliamM]

I am getting a hex byte (ie. "\x4D") which I want to print to STDOUT so I can see it. To do this, I thought it would be easiest to use the pre-made functions in hexSupport.py. So I wrote:

print byte # for debugging
temp = int(byte)
print temp # for debugging
printHex(temp)

On my output I get:

M # the equivalent of 4D
29 # NOT the integer equivalent of 4D which is 77
1D # the hex equivalent of 29

What's going wrong? In the description of int() it says "Returns the integer representation of the object", with no exact definition for "object".

[WilliamM]

I am using int() because in printHex() it says:
''print a byte in hex - input is an integer, not a string'''

[admin]

What's going wrong? In the description of int() it says "Returns the integer representation of the object", with no exact definition for "object".

Our version of int is slightly different than standard Python in that we don't accept a base as the second argument. Because of this we expect the string you pass in to be a base 10 string like "1234". When you pass something like "\x4D" that is not in base 10, the conversion will be incorrect like you are seeing.

[WilliamM]

Ok. But how can I print a hexadecimal byte? (and have it read "4D" not "M")

[admin]

Ok. But how can I print a hexadecimal byte? (and have it read "4D" not "M")

Use the "dumpHex" function in hexSupport.py

[WilliamM]

dumpHex() does work directly, but I'm seeing the same problem I saw before with mac addresses - which is that i cannot pass my hex string to another variable and have it remain the same hex string. Ie

responderAddr = rpcSourceAddress()[:]
firstAddr = responderAddr

won't work. firstAddr will have a value different from the original. We avoided this earlier by just substituting the function rpcSouceAddress()[:] everywhere where I was going to use the variable responderAddr. Now I can't do that because my hex string is coming in through the STDIN hook into a different function.

I think it was Mark who advised us about the mac addresses in an email, but part of that problem is described in the forum post "node triangulation".

[kbanks]

I think you have misunderstood the "string buffer" limitations in 2.0/2.1.

It's not that you can't have more than one string referring to the "slice" buffer.

Here for example is a test script I just ran in a SNAP 2.1.8 node.


def strTest():
str1 = rpcSourceAddr()[:]
str2 = str1
rpc("\x00\x00\x0c","rdump",str1)
rpc("\x00\x00\x0c","rdump",str2)


(Portal is running the rprint.py script that has already been posted on the forum)

Both str1 and str2 appear in Portal as the same string (which is correct).

The problem comes if you later do something else that requires the "slice buffer". THEN you will have affected BOTH str1 and str2.


def strTest():
str1 = rpcSourceAddr()[:]
str2 = str1
str3 = "ABC"
str4 = str3[:]
rpc("\x00\x00\x0c","rdump",str1)
rpc("\x00\x00\x0c","rdump",str2)


When you run the above function, you will see both strings reported as "ABC", neither one is the original RPC source address.

With 2.0/2.1, you have one "slice buffer", one "concat buffer", and one "single character subscript buffer" to work with.

You can force a string to be "in" the "concat buffer" by doing a concatenation, something like:

a = '' + a

You can force a string to be "in" the "slice buffer" by doing something like:

a = a[:]

Strings are "in" the "one character subscript buffer" when you do something like:

a = b

You also have the option of saving a string into a NV parameter, and retrieving it later.

(All of this was covered in the SNAP 2.1 Reference manual)

If you are unable to do your needed string processing with the above tricks, then you will have to migrate over to version 2.2, where we added approx. 7 dynamic string buffers to get around all of the above limitations (you still won't be able to do [I]unlimited string processing).