Re: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

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

>For what matters, luaview has an emulated stdout in a LV window, as support
for the print statement. But luaview has certainly

>a much more complex handling of the interaction with LV, and can run
asynchronously. A developer could perhaps say how

>difficult could be to implement such a feature .

 

Actually LuaVIEW does this by starting up a background deamon in LabVIEW
that receives those messeages from a queue. Neat but

quite involved, and it makes all kinds of involved initialization behind the
scenes necessary. Definitely not what I had intended to do

with LabPython.

 

>I can add a further wish: support for more input/output types. For instance
I find myself dealing with images, which are large

>matrices of U8, and I would be forced to cast them to I32 in LV and
downcast back to U8 in python; that is a detour and requires

>extra memory and time. (currently I convert them to strings, bytearray and
reshape them in python, which wastes less memory

>but is still a detour).



This is a limit by Python itself. Maybe newer versions support additional
types but when I worked on LabPython the only internal supported

basic datatypes in Python were Int, Long, Real and Complex. I did not find
it useful to make involved conversions between all possible

LabVIEW datatypes to these four basic Python types. And no, optional modules
like numpy or such are not a good option. There was no

good C API to access modules with, that could or could not be present. That
is also why I implemented arrays as lists. The array datatype

was only in an optional module whose use was discouraged at that time.

 

Rolf Kalbermatter

CIT Engineering Netherlands BV