Re: [LabPython-Users] Updates to the project

[Rolf K. <rol...@gm...>]

Hi Daniele

I think you got all relevant people who have ever provided something to
this project. Basically the C code is all from me, Jim Kring helped with
some of the LabVIEW VIs and testing and the website.

I don't have the interest and the time to dig into LabPython at this time
so if you want to go with your own, then you are free to do so. Just notice
that LabPython was and still is LGPL licensed so you can't relicense it
under a different license at this point.

The dynamic loading of both the Python core and the lvpython part from
within pytscript is actually not just a random complication. The Python
kernel was loaded dynamically since the Python developers choose to release
every new Python version with a different shared library and that would
have made a new release of LabPython necessary for every new Python
release. This worked fine until Python 2.7 which introduced certain changes
in preparation of 3.0 that broke the ABI of the Python shared library.
Removing that will certainly make maintenance of LabPython to work with
more than one single Python version more complicated than easier.

The separation of pytscript and lvpython was done for a different reason.
pytscript in order to work has to be in a very specific location inside
LabVIEW. Anywhere else and the script interface will not recognize the
shared library as scripting server. But that location is not in any of the
paths that LabVIEW will search for shared libraries when used in a Call
Library Node. This makes the whole setup for the LabVIEW VI interface very
brittle and easy to break as the VIs can and sometimes will loose the link
to the location of that shared library when installed into a non standard
LabVIEW system. And when building applications these locations are
different again. By using dynamic linking it is fairly easy to add
additional search paths to the loader rather than havi g to changge a
system global PATH environment variable or similar.

>From the two interfaces pytscript and the LabVIEW VIs I consider the
LabVIEW VI interface the much more useful one, as the scripting interface
can not work with runtime changable scripts. The text of a script is
compiled into the VI at compile time and cannot be changed at runtime (well
it can in the development environment with VI scripting, provided the VI in
question is not part of a running VI hierarchy, but that is a Gorilla
approach to runtime changable scripts and will not work in an executable at
all). Rather than removing the dynamic interface between pytscript and
lvpython I would simply remove the enitre pytscript. That makes a lot more
sense.

Stability problems of LabPython are most likely due to the fact that Python
isn't multitreading safe while LabVIEW will execute Call Library Nodes not
set to run in the UI thread in any of the multiple threads that every
executable system has. Changing the Call Library Nodes to run in the UI
thread is a terrible limitation that will block LabVIEW UI changes whenever
you execute a Python VI that takes more than a few microseconds to do its
stuff and eliminate any possibility to do load sharing with multiple python
sessions,  but adding thread synchronization to each lvpython function to
make sure a particular python context is only invoked from the same thread
is going to be a project where the dynamic loading of shared library calls
looks like peanouts in comparison. It's not something I feel inclined to
work on at the moment. Basically calling thread unsafe code from a
multithreading environment either requires mutex protection of each
resource or thread synchronisation or somethimes even both, which would be
a very good way to create self locking code very easily without VERY
tedious discipline in the C code and possibily even in the LabVIEW code.

Sincerely

Rolf Kalbermatter