labpython-users — LabPython users mailing list

Re: [LabPython-Users] Python v2.5

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

Hi Ian

Sorry for the delay in replying.  I sent an email about 8 days ago, but it
doesn't seem to have been delivered.

 

Thanks for the updated package.

I tried to install today, but got the following error message:

 

 

==============

 

Main Package Name: oglib_labpython-1.2-1

Package Name with Error: oglib_labpython-1.2-1

Error Message: VIPM could not install the package oglib_labpython-1.2-1 .

Error Code: 15

Error Source: (File "File Group 2/lvpython.dll" not found in package)
D05176DD379A1C8037BFF6EC4C40F6EC in
1A803725D0FF91C5780DDC8F737CC4BE->80DBEEE796D367A1F20720A7F185BBF0->08D23E9A
0EB2618FD3FCE25BCDE8F285.lvlib:DBF4AEE2E95A4BEA200FF7A642ED0332->08D23E9A0EB
2618FD3FCE25BCDE8F285.lvlib:7454D3E0FBCF041E4CD97C77AADCB821->3172DE97E266CD
4EBFAC73CFCD5A02E2->VIPM Main Window.vi

 

===============

 

I used VIPM 1.1 Beta 2 (build 0622) and I( am running Labview 7.1. 



I didn't test with VIPM. As I do all the OpenG development still in 6.x I
used the old OpenG Package Manager that I have still installed and that did
work fine. Also looking into the archive I can see the file it claims
shouldn't be there. Can you verify that the archive didn't get corrupted
somehow, by renaming the package into .zip and looking for the file in there
with a zip utility?
 
Rolf Kalbermatter

Re: [LabPython-Users] Python v2.5

[Ian P. <ian...@er...>]

Hi Rolf,

=20

Sorry for the delay in replying.  I sent an email about 8 days ago, but
it doesn't seem to have been delivered.

=20

Thanks for the updated package.

I tried to install today, but got the following error message:

=20

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20

Main Package Name: oglib_labpython-1.2-1

Package Name with Error: oglib_labpython-1.2-1

Error Message: VIPM could not install the package oglib_labpython-1.2-1
.

Error Code: 15

Error Source: (File "File Group 2/lvpython.dll" not found in package)
D05176DD379A1C8037BFF6EC4C40F6EC in
1A803725D0FF91C5780DDC8F737CC4BE->80DBEEE796D367A1F20720A7F185BBF0->08D2
3E9A0EB2618FD3FCE25BCDE8F285.lvlib:DBF4AEE2E95A4BEA200FF7A642ED0332->08D
23E9A0EB2618FD3FCE25BCDE8F285.lvlib:7454D3E0FBCF041E4CD97C77AADCB821->31
72DE97E266CD4EBFAC73CFCD5A02E2->VIPM Main Window.vi

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20

I used VIPM 1.1 Beta 2 (build 0622) and I( am running Labview 7.1.

=20

Any ideas?

=20

Thanks again for your help.

=20

Cheers

Ian

=20

________________________________

From: lab...@li...
[mailto:lab...@li...] On Behalf Of Rolf
Kalbermatter
Sent: 02 November 2007 19:48
To: 'LabPython Users Mailing List'
Subject: Re: [LabPython-Users] Python v2.5

=20

Hi Ian,

=20

	I am currently using Labpython 1.1, and have found that it only
works with Python 2.3.4 or below.

	In your previous post you mentioned that you had made some
changes to allow labpython to work with v2.5, but it was not tested.

	Have you managed to complete any testing and are you willing to
produce an update package?

	I have had a look at the CVS code
(http://labpython.cvs.sourceforge.net/labpython/labpython/) and notice
that version 1.3 seems available, but it is unclear which files I need,
and in which directory they should be placed.

=20

I'm currently very busy and have little time to work on this. The
version you noticed is simply the CVS version number.

The package in itself would be probably 1.2. And no I haven't found time
(and motiviation) to do much more testing.

=20

I do believe that it should sort of work but building the package is due
to the nature of this a bit tricky. Included is a

prelimenary package build that you should be able to install with VIPM.
Obviously a Python 2.5 needs to be present

too, unless you register a different python DLL as server with "PYTHON
Set Server Path".

=20

Let me know if you have troubles and also if it works for you.=20

=20

Rolf Kalbermatter

[LabPython-Users] Python v2.5

[Ian P. <ian...@er...>]

Hi Rolf,

=20

I am currently using Labpython 1.1, and have found that it only works
with Python 2.3.4 or below.

In your previous post you mentioned that you had made some changes to
allow labpython to work with v2.5, but it was not tested.

Have you managed to complete any testing and are you willing to produce
an update package?

I have had a look at the CVS code
(http://labpython.cvs.sourceforge.net/labpython/labpython/) and notice
that version 1.3 seems available, but it is unclear which files I need,
and in which directory they should be placed.

=20

Appreciate your help

=20

Cheers

Ian

Re: [LabPython-Users] Problems running the Labpython scripting node

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

Hi Mirko
 
> First I hope that this mailing list is still active.

Yes it is! :-) Although no real activity.
 
>I installed the labpython package with OpenG and have the problem that
Labview can not
>start the scripting server: "Error1046: LabVIEW cannot initialize the
script server.  Ensure
>the server software is installed." I'm using Labview 8.2 and Python 2.5
inside of an PyGTK
>installation. Path Variables are set to the Python directory.
>
>Do I need another (or older?) Python installation? Do you have somewhere
some instructions
>how to install the Labpython scripting node properly? 
 
You don't mention what version of the LabPython package you downloaded.
 
The currently released LabPython package 1.1 on source forge is compiled for
Python 2.2 if I'm not mistaken. I have tried it with 2.4 at some point but
not really made any tests. The dependency on a specific Python sub version
is something that is dictated by the Pyton policy of naming each Python DLL
according to its version. This is also so because Python reserves the right
to introduce binary incompatiblities between versions.
 
Also testing for LapPython has been really only done for LabVIEW 6.0 and
6.1. So there is a potential problem that the scripting node API interface
might have changed at some point in LabVIEW. The information used to create
LabPython is from an NI source but not an official documentation and
therefore NI reserves the right to make changes to this whenever they like.
 
LabPython has a (rather complicated mechanisme) to link dynamically to the
Python server DLL. But without setting the actual Python DLL path with the
function PYTHON Set Server Path.vi to point to the actual new Python DLL it
will try to load the default Python DLL which is python22.dll. And since it
does not know about the entire path this DLL also has to be in the DLL
search path (eg. Windows, or System directory or a directory specified in
the PATH environment variable). Also pointing this path to anything but a
real Python DLL will also cause the labpython DLL to return an error to
LabVIEW.
 
Fixing this should at least get rid of the server not found error but won't
guarantee that it will work with newer Python versions due to possible
binary incompatibilities with the called Python APIs.
 
That said I have done a little work on LabPython at the end of last year,
integrating a few fixes and improvements and also updating LabPython to link
to the Python 2.5 library instead. However no serious testing has been done
and consequently no package has been build so far. Also due to some
workarounds necessary the whole is now split into two DLLs that do work
together to allow using the LabVIEW VI API and the script node at the same
time in the same LabVIEW program without crashing. But as said no serious
testing yet however and no packages either.
 
You can however get the actual C source with these changes from the
sourceforge servers in the LapPython project.
Rolf Kalbermatter

[LabPython-Users] Problems running the Labpython scripting node

[Mirko S. <mir...@gm...>]

Hi everybody,

First I hope that this mailing list is still active.

I installed the labpython package with OpenG and have the problem that
Labview can not start the scripting server: "Error1046: LabVIEW cannot
initialize the script server.  Ensure the server software is installed." I'm
using Labview 8.2 and Python 2.5 inside of an PyGTK installation. Path
Variables are set to the Python directory.

Do I need another (or older?) Python installation? Do you have somewhere
some instructions how to install the Labpython scripting node properly?

Thank you very much,
Mirko

RE: [LabPython-Users] Question about Labpython and Labview under Linux

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

Stappers, F.P.M. wrote:

> I've installed Linux (SuSE-10.0), Python 2.2.3, Labview7, 
> OpenG and Labpython under Linux. However when I try want to 
> to output my a connector I'm not able to select a datatype. 
> 
> However when I do the same under MS Windows it al works fine. 
> So my question is, what am I doing wrong.
> 
> PS: Everything is correct installed and I think it has 
> something to do with the python22.dll (which is for windows 
> offcourse).

LabPython has not really been tested for Linux yet as I never
tested if and how the scripting interface would need to be
adapted to work for LabVIEW for Linux. You would definitely
need to create the Linux shared library first and install that
One into your LabVIEW folder. But the last version I created
crashed LabVIEW consistently. Putting pyscript.dll into the
according LabVIEW resource folder will not do anything as this
is a Windows shared library and can't be loaded by LabVIEW for
Linux nor will it even attempt to.

Python22.dll can't possibly work eitehr since it is Windows too
and there would need to be a pythonXX.so instead on your system
for the scripting interface library to link to.

But as said my tests with LabPython on Linux were very limited
And there seems to be a regression in some revision of Python 2.4
that was caused by a security fix to Python that prevents LabVIEW
from unloading the script node shared library after it has been
used. This is under Windows but I would expect a similar problem
under Linux too.

Currently I have no time to spend on investigating this LabPython
Problem nor on trying to figure out how this needs to be configured
to work under various Linux and LabVIEW versions.

Rolf Kalbermatter

[LabPython-Users] Question about Labpython and Labview under Linux

[Stappers, F.P.M. <F.P...@st...>]

Dear reader,

I've installed Linux (SuSE-10.0), Python 2.2.3, Labview7, OpenG and =
Labpython under Linux. However when I try want to to output my a =
connector I'm not able to select a datatype.=20

However when I do the same under MS Windows it al works fine. So my =
question is, what am I doing wrong.

PS: Everything is correct installed and I think it has something to do =
with the python22.dll (which is for windows offcourse).

Hope to get a quick respond.

Yours faithfully,
Frank Stappers

RE: [LabPython-Users] Hello

[I P. <I.P...@ma...>]

Hi Rolf, Joakim,

I was wondering if you could help with the following problem.
I have a class that redirects the print statement to a Tkinter window, see 
below.
The test script (testprint.py) works fine under a python shell.

However, when I try to run the same script in LabPython, I get the 
following error:
        "exceptions.AttributeError, 'module' object has no attribute 
'argv'" (Script fails at "root=Tk()" statement)

Am I doing something silly? or can't LabPython open any GUI windows?
(NOTE: I typically use PYTHON set script.vi and PYTHON Execute script.vi.)

Your thoughts
Thanks for your help

Ian

---------------------------------------
##filename = testprint.py
from Tkinter import *
from printtogui import *


root = Tk()
text = Tktextfile(root)
logger = Logger(text)
for i in range(6):
    print "%d, " %i
-----------------------------------------
## filename = printtogui.py

"""A short python script for re-directing print statement."""

import os, os.path, tkFileDialog
from Tkinter import *
 
class Logger:
    """A filelike object that prints its input on the screen."""
 
    def __init__(self, logfile=None):
        """Takes one argument, a file like object for logging."""
        print 'Starting logger...'
        if not logfile:
            self.logfile = open('relative-refs.log','w')
        else:
            self.logfile = logfile
        sys.stderr = self                 # Super cheap logging 
facility...
        sys.stdout = self                 # Just redirect output to a 
file.
        print 'Logger running...'
 
    def write(self, line):
        sys.__stdout__.write(line)
        self.logfile.write(line)
 
    def close(self):
        """The close method restores stdout and stderr to normal."""
        self.logfile.close()
        sys.stderr = sys.__stderr__
        sys.stdout = sys.__stdout__

class Tktextfile:
    """A file like interface to the Tk text widget."""
 
    def __init__(self, root):
        """Create a scrollable text widget to be written to."""
        self.root = root
        self.text = Text(root,width=40,height=20)
        self.text.pack(side=LEFT, expand=True, fill=BOTH)
        scrollbar = Scrollbar(root)
        scrollbar.pack(side=RIGHT,fill=Y)
        self.text.configure(yscrollcommand=scrollbar.set)
        scrollbar.config(command=self.text.yview)
        self.text.focus()
 
    def write(self, line):
        """Write method for file like widget."""
        self.text.insert(INSERT, line)
        self.text.see(END)
 
    def close(self):
        """Fake close method."""
        pass
-------------------------------------------------




"Rolf Kalbermatter" <rol...@ci...>
Sent by: lab...@li...
21/12/2005 00:23
Please respond to labpython-users

 
        To:     <lab...@li...>
        cc: 
        Subject:        RE: [LabPython-Users] Hello


Hi Joakim,
> 
> >Chances are that there is no good solution which works both for pre
> 2.3.5 and later.
> 
> Sounds like you are approaching the source already! Hope it 
> affects only pyimport.c?

Nope it is more likely affecting lvpython.c and in there PyCloseHost and 
there
again the use of PyEval_.. functions as well as probably 
PyThreadState_Swap().
It is definitely in there where LabVIEW hangs indirectly when trying to 
unload
the script DLL.

> >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.
> 
> I see. 
> Would you like to point me to where I can find docs about the LabVIEW
> API for script nodes? I would like to have types for waveform plots and
> xy plots. I have problems generating those types when calling LabVIEW
> VIs from Python through win32com because that module doesn't distinguish
> between tuples (clusters) and lists (arrays). I guess that module uses
> OLE variants.

I'm not aware of official documentation for the script node API. Basically
I did start out to reverse engineer that API and then Jim Kring managed to
get in touch with a LabVIEW developer who was willing to give us the 
header
file defining that API as used in LabVIEW 6.0. As far as that is concerned
it basically just confirmed most of the things I had already found out and
it was more or less what is now in lvpython.h except some of the comments
in there which I had added myself before, based on my own findings.
I'm sure the script node in current LabVIEW version has some more features
added but that is of little importance for labpython up to this moment.

If you interface LabVIEW through win32com then you interface through COM
(which was called OLE and now listens to the name of ActiveX) and as such
you will eveidently see OLE variants. Waveforms are basically LabVIEW 
variants
but LabVIEW takes care of  converting from its own variants to OLE 
variants
when you interface the ActiveX interface of LabVIEW.

Rolf Kalbermatter



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
LabPython-Users mailing list
Lab...@li...
https://lists.sourceforge.net/lists/listinfo/labpython-users

RE: [LabPython-Users] Hello

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

Hi Joakim,
> 
> >Chances are that there is no good solution which works both for pre
> 2.3.5 and later.
> 
> Sounds like you are approaching the source already! Hope it 
> affects only pyimport.c?

Nope it is more likely affecting lvpython.c and in there PyCloseHost and there
again the use of PyEval_.. functions as well as probably PyThreadState_Swap().
It is definitely in there where LabVIEW hangs indirectly when trying to unload
the script DLL.

> >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.
> 
> I see. 
> Would you like to point me to where I can find docs about the LabVIEW
> API for script nodes? I would like to have types for waveform plots and
> xy plots. I have problems generating those types when calling LabVIEW
> VIs from Python through win32com because that module doesn't distinguish
> between tuples (clusters) and lists (arrays). I guess that module uses
> OLE variants.

I'm not aware of official documentation for the script node API. Basically
I did start out to reverse engineer that API and then Jim Kring managed to
get in touch with a LabVIEW developer who was willing to give us the header
file defining that API as used in LabVIEW 6.0. As far as that is concerned
it basically just confirmed most of the things I had already found out and
it was more or less what is now in lvpython.h except some of the comments
in there which I had added myself before, based on my own findings.
I'm sure the script node in current LabVIEW version has some more features
added but that is of little importance for labpython up to this moment.

If you interface LabVIEW through win32com then you interface through COM
(which was called OLE and now listens to the name of ActiveX) and as such
you will eveidently see OLE variants. Waveforms are basically LabVIEW variants
but LabVIEW takes care of  converting from its own variants to OLE variants
when you interface the ActiveX interface of LabVIEW.

Rolf Kalbermatter

RE: [LabPython-Users] Hello

[Joakim P. \(LD/EAB\) <joa...@er...>]

Hi Rolf,

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

Sounds like you are approaching the source already! Hope it affects only
pyimport.c?

>>sys.stdin =3D 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. ...

Thanks for the correction, "sys.stdin =3D StringIO (stdin)" works!
(Something spooked me yesterday.)

>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=20
>Windows OLE variant and my drive for reverse engineering such an
obscure datatype is close to 0.

I see.=20
Would you like to point me to where I can find docs about the LabVIEW
API for script nodes? I would like to have types for waveform plots and
xy plots. I have problems generating those types when calling LabVIEW
VIs from Python through win32com because that module doesn't distinguish
between tuples (clusters) and lists (arrays). I guess that module uses
OLE variants.

/Joakim

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

RE: [LabPython-Users] Hello

[Joakim P. \(LD/EAB\) <joa...@er...>]

Hello Ian and Rolf,

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

Downgrading Python from 2.4.1 to 2.3.4 was a good workaround for me,
LabVIEW doesn't hang anymore when I close my script VIs. Thanks Ian for
the investigation!

The input() problem can actually be fixed: If the input is known before
execution or can be supplied through an external file, try redirecting
sys.stdin for example like this:

Test with stdin =3D "1\n" (supplied as a LabVIEW string).
--- script ---
try:
    sys
except:
    import sys
    from StringIO import StringIO
    version =3D sys.version

sys.stdin =3D StringIO ("".join (stdin)) # StringIO wants ASCII, LabVIEW
has UNICODE
sys.stdout =3D StringIO ()
sys.stderr =3D StringIO ()

print "Hi there!"
try:
    x =3D input ("Wazzup?")
except:
    sys.stderr.write ("Invalid input")

stdout =3D sys.stdout.getvalue ()
stderr =3D sys.stderr.getvalue ()

sys.stdin =3D sys.__stdin__
sys.stdout =3D sys.__stdout__
sys.stderr =3D sys.__stderr__
--- end script ---
Result: x =3D 1

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?

Best regards,
Joakim

-----Original Message-----
From: lab...@li...
[mailto:lab...@li...] On Behalf Of Rolf
Kalbermatter
Sent: den 16 december 2005 20:24
To: lab...@li...
Subject: RE: [LabPython-Users] Hello

I Phillips wrote:

>I have tracked down the bug to Python 2.3.5.=20
>i.e. if you install any version upto and including Python 2.3.4, then
the bug isn't present.=20
>
>The big thing that sticks out in the python release between v.2.3.4 and

>v2.3.5 is a security patch
(http://www.python.org/security/PSF-2005-001/).
>"Note that these patches disable recursive traversal."=20
>
>I am not an expert in python or programming, but think that this may be
worth investigating.=20
>
>Are any of the original developers still subscribed to this user group?
>Would you see this as a possible issue?=20

I'm still subscribed and the main original developer but my time is
limited and labpython is not at the top of my priority list.

I will take a look at the mentioned patch when I have some time and see
if that might be the problem. I'm not specifically aware that I used
something called recursive traversal.
Instead I suspect something strange going on with the Python thread
protection or session management. Above mentioned patch might have some
indirect influence on these things though.

>A second bug I have found, is that if the python input("Please enter=20
>your name") command is used, and executed using the Labpython Execute
script.vi then Labview crashes.

This might be a hard one to fix. I suspect some issues with standard IO
clashes as python is really called as a client inside the LabVIEW
process and as such as no default standard IO anymore. Maybe that one
could provide some standard IO redirections going to dialog boxes or
such but that seems like a huge hassle.

Rolf Kalbermatter



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems?  Stop!  Download the new AJAX search engine that
makes searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
LabPython-Users mailing list
Lab...@li...
https://lists.sourceforge.net/lists/listinfo/labpython-users

RE: [LabPython-Users] Hello

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

I Phillips wrote:

>I have tracked down the bug to Python 2.3.5. 
>i.e. if you install any version upto and including Python 2.3.4, then the bug isn't present. 
>
>The big thing that sticks out in the python release between v.2.3.4 and v2.3.5 is a
>security patch (http://www.python.org/security/PSF-2005-001/). 
>"Note that these patches disable recursive traversal." 
>
>I am not an expert in python or programming, but think that this may be worth investigating. 
>
>Are any of the original developers still subscribed to this user group?
>Would you see this as a possible issue? 

I'm still subscribed and the main original developer but my time is limited and labpython
is not at the top of my priority list.

I will take a look at the mentioned patch when I have some time and see if that might be
the problem. I'm not specifically aware that I used something called recursive traversal.
Instead I suspect something strange going on with the Python thread protection or session
management. Above mentioned patch might have some indirect influence on these things though.

>A second bug I have found, is that if the python input("Please enter your name")
>command is used, and executed using the Labpython Execute script.vi then Labview crashes. 

This might be a hard one to fix. I suspect some issues with standard IO clashes as python
is really called as a client inside the LabVIEW process and as such as no default standard
IO anymore. Maybe that one could provide some standard IO redirections going to dialog
boxes or such but that seems like a huge hassle.

Rolf Kalbermatter

RE: [LabPython-Users] Hello

[I P. <I.P...@ma...>]

Hi Joakim,

Thanks for the intro. to Labpython.

I have tracked down the bug to Python 2.3.5.
i.e. if you install any version upto and including Python 2.3.4, then the 
bug isn't present.

The big thing that sticks out in the python release between v.2.3.4 and 
v2.3.5 is a security patch (http://www.python.org/security/PSF-2005-001/).
"Note that these patches disable recursive traversal."

I am not an expert in python or programming, but think that this may be 
worth investigating.

Are any of the original developers still subscribed to this user group? 
Would you see this as a possible issue?

A second bug I have found, is that if the python input("Please enter your name") command is used, and executed using the Labpython Execute script.vi then 
Labview crashes.

If anybody can highlight any other bugs, or help solve the bug above that 
would be great.

Cheers everybody

Ian





"Joakim Pettersson (LD/EAB)" <joa...@er...>
Sent by: lab...@li...
07/12/2005 13:12
Please respond to labpython-users

 
        To:     <lab...@li...>
        cc: 
        Subject:        RE: [LabPython-Users] Hello


Hi Ian,
 
Yes I use the script node and it works with Python 2.4 with some issues:
 
1. Only one script node per VI.
2. LabVIEW hangs when the VI is closed. So I have to kill LabVIEW using 
CTRL+ALT+Delete.
 
The recipe is like this:
 
1. Download the package.
2. Copy pytscript.dll from labpython\File Group 0 to "C:\Program 
Files\National Instruments\LabVIEW 7.1\resource\script". 
5. Copy the labpython\File Group 2\labpython folder into "C:\Program 
Files\National Instruments\LabVIEW 7.1\user.lib" or vi.lib depending on 
where you want the menu to appear in LabVIEW.
3. Open "PYTHON Set Server Path.vi" (in labpython\File Group 2\labpython) 
and execute it with path "C:\WINNT\system32\python24.dll".
4. Test the three VIs in labpython\File Group 3 and then File->Save with 
Options.../Save these. The labpython folder in your user.lib/vi.lib is now 
compiled to use python24.dll so you won't need to run "PYTHON Set Server 
Path.vi" again. 
 
I currently use a Python script VI as a toplevel GUI to a Python object 
that controls the rest of my mostly LabVIEW-based test system. So when I 
run the script, a number of subVIs open up and stay in run mode until I 
delete my test object in the script. 
 
Because of the bug 2 above, I plan to move the toplevel script into a 
pyton file that uses the GUI as a subVI instead. I can send the neat 
LabVIEW.py file I use to remote LabVIEW if you like (it runs on top of the 
win32com module).
 
I took a look at the C code for the pytscript.dll and I think the bug is 
that the dll doesn't disconnect the session with the Python interpreter 
properly. It should probably call sys.exit () as cleanup when the VI is 
closed, but it was not obvious to me where I should do that. I got stuck 
because I didn't find the API description for LabVIEWs script node and I 
can live with the bug for a while.
 
Please notify if you can't get it to work using the recipe above or if you 
dig further into the C code or get rid of the bug somehow.
 
Best wishes,
Joakim
 

From: lab...@li... 
[mailto:lab...@li...] On Behalf Of I Phillips
Sent: den 7 december 2005 12:12
To: lab...@li...
Subject: [LabPython-Users] Hello


Hi everybody, 

Anybody currently using LabPython ? 

I have been using Labview for years, and have just started writing scripts 
in Python, so I thought now was a good time to integrate the two. 

Any examples/tips/known issues would be welcome. 

Thanks in advance 

Ian

RE: [LabPython-Users] Hello

[Joakim P. (LD/EAB) <joa...@er...>]

Hi Ian,
=20
Yes I use the script node and it works with Python 2.4 with some issues:
=20
1. Only one script node per VI.
2. LabVIEW hangs when the VI is closed. So I have to kill LabVIEW using
CTRL+ALT+Delete.
=20
The recipe is like this:
=20
1. Download the package.
2. Copy pytscript.dll from labpython\File Group 0 to "C:\Program
Files\National Instruments\LabVIEW 7.1\resource\script".=20
5. Copy the labpython\File Group 2\labpython folder into "C:\Program
Files\National Instruments\LabVIEW 7.1\user.lib" or vi.lib depending on
where you want the menu to appear in LabVIEW.
3. Open "PYTHON Set Server Path.vi" (in labpython\File Group
2\labpython) and execute it with path "C:\WINNT\system32\python24.dll".
4. Test the three VIs in labpython\File Group 3 and then File->Save with
Options.../Save these. The labpython folder in your user.lib/vi.lib is
now compiled to use python24.dll so you won't need to run "PYTHON Set
Server Path.vi" again.=20
=20
I currently use a Python script VI as a toplevel GUI to a Python object
that controls the rest of my mostly LabVIEW-based test system. So when I
run the script, a number of subVIs open up and stay in run mode until I
delete my test object in the script.=20
=20
Because of the bug 2 above, I plan to move the toplevel script into a
pyton file that uses the GUI as a subVI instead. I can send the neat
LabVIEW.py file I use to remote LabVIEW if you like (it runs on top of
the win32com module).
=20
I took a look at the C code for the pytscript.dll and I think the bug is
that the dll doesn't disconnect the session with the Python interpreter
properly. It should probably call sys.exit () as cleanup when the VI is
closed, but it was not obvious to me where I should do that. I got stuck
because I didn't find the API description for LabVIEWs script node and I
can live with the bug for a while.
=20
Please notify if you can't get it to work using the recipe above or if
you dig further into the C code or get rid of the bug somehow.
=20
Best wishes,
Joakim
=20
________________________________

From: lab...@li...
[mailto:lab...@li...] On Behalf Of I
Phillips
Sent: den 7 december 2005 12:12
To: lab...@li...
Subject: [LabPython-Users] Hello



Hi everybody,=20

Anybody currently using LabPython ?=20

I have been using Labview for years, and have just started writing
scripts in Python, so I thought now was a good time to integrate the
two.=20

Any examples/tips/known issues would be welcome.=20

Thanks in advance=20

Ian

[LabPython-Users] Hello

[I P. <I.P...@ma...>]

Hi everybody,

Anybody currently using LabPython ?

I have been using Labview for years, and have just started writing scripts 
in Python, so I thought now was a good time to integrate the two.

Any examples/tips/known issues would be welcome.

Thanks in advance

Ian

[LabPython-Users] more labpython examples?

[Jeffrey L. W. <jef...@ph...>]

I just installed labpython.  There were some bugs with the location of the
files, namely the labpython VI's try to find the pytscript.dll file in the
<labview>/user.lib/labpython directory instead of
<labview>/resource/script.  However, fixing this on one of the labpython
items in the palette seems to have fixed it for the others.

I'm using labpython on Windows XP (and python 2.3) if that matters.  I
was able to access the python23.dll file by manually setting it in the
"PYTHON Set Server Path" VI.  Does anybody know if these two DLL's are
compatible in terms of datatypes and order of passed parameters?  I
haven't noticed any problems yet, although I've only done very limited
things so far.

Are there any more labpython examples available other than the three that
come bundled with the OGP file?

I'm also curious if it's possible to call LabVIEW VI's from the python
script.  I'd like to set up a script such that I can control which of my
subVI's will get executed, but I'm not sure how to do that with the
current version of labpython that I'm using.

Is anybody else still actively using labpython?  This list seems awfully
quiet this year.

	Thanks,

	- Jeffrey Wasserman

RE: [LabPython-Users] Project status/ Python 2.3

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

Jon Fox wrote:

> The installation is on WindowsXP (yuck!) and unfortunately I don't have a
> copy of MS VC, so for now I'll try LabPython with python 2.2. If that works
> and I get ambitious I'll try and get my hands on VC6 and try to recompile.

Well as said there should be actually a VI, called "PYTHON Set Server Path.vi"
to actually change the python DLL the intermediate DLL is trying to link to.
I'm not really sure anymore how well that worked once the DLL was already used
for executing a Python script and in such might have a problem if you try to
change the path while a VI is loaded which uses the scrupt node configured to
use the Python plugin or try to change the path while there has been an
interactive session (the VI library interface of LabPython) opened but it did
work at some place for sure when called as first function in a LabVIEW program
before any other LabPython VIs on my Windows 2000 system with a prelease 2.3
python DLL.

> Right now I'm a gcc 3.4 man.

You should be able to create Windows DLLs with the MinGW toolchain which is
based on gcc as compiler. But I never tried this as I'm lazy and have Visual C
already installed for my other work on this machine.

> Thanks for the input. Perhaps I'll come to like G.

Well for scripting Python is a lot better. But for application development I
definitely prefer LabVIEW (and also can understand it much better ;-).

Rolf Kalbermatter
CIT Engineering Nederland BV    tel: +31 (070) 415 9190
Treubstraat 7H                  fax: +31 (070) 415 9191
2288 EG Rijswijk	http://www.citengineering.com
Netherlands		mailto:rol...@ci...
  

Re: [LabPython-Users] Project status/ Python 2.3

[<the...@na...>]

Rolf:

The installation is on WindowsXP (yuck!) and unfortunately I don't have a copy of MS VC, 
so for now I'll try LabPython with python 2.2. If that works and I get ambitious I'll try 
and get my hands on VC6 and try to recompile.  Right now I'm a gcc 3.4 man.

Thanks for the input. Perhaps I'll come to like G.

-- Jon

On Fri, Sep 24, 2004 at 11:50:41AM +0200, Rolf Kalbermatter wrote:
> Jon Fox wrote:
> 
> > I'm a devoted pythonista and have to grudgingly use LabVIEW on a project for
> > the next few months. I've got python 2.3 and favorite python site-packages
> > already installed on said machine, and am wondering how difficult it would be
> > to compile labpython for python 2.3 and what roadblocks I should expect to
> > running labpython with 2.3. 
> 
> Well, as the original developer of that library I would like to make some comments
> to your questions.
> 
> A recompilation is quite simple. On Windows you need Visual C (I prefer version 6
> as version 7 with .Net adds all sorts of dependencies to your Windows installation.
> There is one single variable which defines to which Python DLL the LabPython code
> should be dynamically linked to on loading. In fact the LabPython DLL even has a
> mechanisme to link dynamically to another Python DLL through calling a specific VI,
> however this mechanisme hasn't been tested throughly and not at all on Linux
> (I believe I couldn't get it work as intended there, as I don't understand shared
> library relinking as well under Linux then I do under Windows) so not sure if it
> could even work for you. Also this assumes that Python didn't do any binary API
> changes between 2.2(.1) and 2.3. If they did it would likely require some changes
> to the LabPython library itself.
> 
> > Is the project still active, or has it largely been abandoned?
> 
> I haven't had the need to do anything with it lately and support from other
> users has been minimal. If you know how to use a C compiler to do at least a
> correct recompilation there should be no real problem. Otherwise my time is
> at the moment very limited so I won't be able to do many modification and even
> less to extensively test and debug any of them.
> 
> Rolf Kalbermatter
> CIT Engineering Nederland BV    tel: +31 (070) 415 9190
> Treubstraat 7H                  fax: +31 (070) 415 9191
> 2288 EG Rijswijk	http://www.citengineering.com
> Netherlands		mailto:rol...@ci...
>  
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> LabPython-Users mailing list
> Lab...@li...
> https://lists.sourceforge.net/lists/listinfo/labpython-users

-- 
.*. Dr. Jon R. Fox
..* http://www.drfox.com
*** jo...@dr...

RE: [LabPython-Users] Project status/ Python 2.3

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

Jon Fox wrote:

> I'm a devoted pythonista and have to grudgingly use LabVIEW on a =
project for
> the next few months. I've got python 2.3 and favorite python =
site-packages
> already installed on said machine, and am wondering how difficult it =
would be
> to compile labpython for python 2.3 and what roadblocks I should =
expect to
> running labpython with 2.3.=20

Well, as the original developer of that library I would like to make =
some comments
to your questions.

A recompilation is quite simple. On Windows you need Visual C (I prefer =
version 6
as version 7 with .Net adds all sorts of dependencies to your Windows =
installation.
There is one single variable which defines to which Python DLL the =
LabPython code
should be dynamically linked to on loading. In fact the LabPython DLL =
even has a
mechanisme to link dynamically to another Python DLL through calling a =
specific VI,
however this mechanisme hasn't been tested throughly and not at all on =
Linux
(I believe I couldn't get it work as intended there, as I don't =
understand shared
library relinking as well under Linux then I do under Windows) so not =
sure if it
could even work for you. Also this assumes that Python didn't do any =
binary API
changes between 2.2(.1) and 2.3. If they did it would likely require =
some changes
to the LabPython library itself.

> Is the project still active, or has it largely been abandoned?

I haven't had the need to do anything with it lately and support from =
other
users has been minimal. If you know how to use a C compiler to do at =
least a
correct recompilation there should be no real problem. Otherwise my time =
is
at the moment very limited so I won't be able to do many modification =
and even
less to extensively test and debug any of them.

Rolf Kalbermatter
CIT Engineering Nederland BV    tel: +31 (070) 415 9190
Treubstraat 7H                  fax: +31 (070) 415 9191
2288 EG Rijswijk	http://www.citengineering.com
Netherlands		mailto:rol...@ci...
=20

[LabPython-Users] Project status/ Python 2.3

[Jon F. <jo...@dr...>]

I'm a devoted pythonista and have to grudgingly use LabVIEW on a project for
the next few months. I've got python 2.3 and favorite python site-packages
already installed on said machine, and am wondering how difficult it would be
to compile labpython for python 2.3 and what roadblocks I should expect to
running labpython with 2.3. 

Is the project still active, or has it largely been abandoned?

-- Jon


-- 
.*. Dr. Jon R. Fox
..* http://www.drfox.com
*** jo...@dr...