Timo Schroeder

Is this not already handled by getObject https://github.com/MDSplus/mdsplus/blob/ad08c9cc7c88f7eed946bf06f2bd6a90e2e1a25f/python/MDSplus/connection.py#L321

why not adding a putObject() which would do serialization under the hood instead of tempering with get and put something like: ``self.get("TreePut($, `serializein($))", node, data.serialize())`` i dont see how this...

so why not adding getObject to the other interfaces instead.

I get that .. hence you would use `getObject()` and `putObject()` for you new code but allow older software to use `get()` and `put()` as usual. In particular you should...

The corresponding line to decide would be here. https://github.com/MDSplus/mdsplus/blob/a8b4e01560da8a262f9b0bfa8af3b54af959c590/treeshr/RemoteAccess.c#L1563 however, I did not find a reliable way to check if it is supported. It is highly recommended to work on...

maybe one can test this and/or write an appropriate unit test

hm if the data gets into Float32 via deserialization, it should contain the original byte code of a F_Float. the tdicall should use this byte code unchanged and feed it...

it seems the problem is that mdsip supports neither F_FLOAT nor G_FLOAT nor D_FLOAT as argument extension. ```tdi mdsconnect('thread://1') Connected: user 1 mdsvalue('DECOMPILE($)', 1.234G0) "1.234D0" ``` As you can see...

@santorofer this time it should work, took me long enough to pick this one up again but here it hopefully is ;)

> This problem was introduced with PR #2288 on 19-May-2021. The bug appears to only affect the `dispatch` command of `TCL`. Thus, it is likely that the associated fix is...