RE: [LabPython-Users] Hello

[Rolf K. <r.k...@hc...>]

Hello Joakim,

>Good to hear from you Rolf and thanks for a nice open-source package! It
>could be great if you could find sime time to have a look at the Python
>2.3.5 problem. 

I will see what I can do. If it is where I'm thinking it is, then it is
a real bitch to fix. The threading protection API in Python is a little
obscure and sort of misnamed as well. It is more about a context than
real threading and I remember having fiddled quite a lot with that part
back when I did develop the labpython interface and while I tried to apply
a logical approach, it finally came down to some trial and error too.

Chances are that there is no good solution which works both for pre 2.3.5
and later.

>sys.stdin = StringIO ("".join (stdin)) # StringIO wants ASCII, LabVIEW
>has UNICODE

This sounds wrong. I'm positive that any string parameters LabVIEW passes
to a script are in ASCII. LabVIEW positively does not support nor use
UNICODE at all but uses internally multi-byte strings for it's user
interface when necessary while the strings in your diagram are always ASCII.

>Adding to a wishlist for labpython: A Variant data type in the pop-up
>menu (on script node variables and the polymorphic "Python Set/Get data"
>VI). Would be really great to have! Is this feasible Rolf?

No! The variant datatype as used in LabVIEW is not documented, nor are any
of the LabVIEW manager functions needed to deal with this datatype. It is
positively not directly compatible with a Windows OLE variant and my drive
for reverse engineering such an obscure datatype is close to 0.

Rolf Kalbermatter