[LuaVIEW-users] Modified 'pull flat data'

Andy Reding ATReding at GWLISK.com
Thu Apr 19 11:52:56 BRT 2007


Mike,

	I'm not actually on the LuaVIEW team (I'm just another user like
you), so I can't comment on whether the debugging mechanism could be
integrated into the core. I seem to remember there being some discussion
on debugging somewhere in the luaview documentation. I've just been
replying because like you, I've often wanted to have a way to pass
general data types between scripts. Wish I could offer more help than
that, sorry.

	However, I think you can do something like this to get your
functions publically available:

register.public_dir("/path to your directory of function vi's/")

	Once this call is made, the public registry in luaview will
contain a list of all your luaview functions in the library. That way,
you don't need to modify the task scripts that you load later - they
will automatically have all the debugging calls registered.

	Does that help?
		Andy


-----Original Message-----
From: luaview-users-bounces at lists.luaforge.net
[mailto:luaview-users-bounces at lists.luaforge.net] On Behalf Of Mike
Sachs
Sent: Thursday, April 19, 2007 10:38 AM
To: A forum for LabVIEW programmers that use LuaVIEW
Subject: Re: [LuaVIEW-users] Modified 'pull flat data'


Hey Andy,

Thanks for your reply.  You are right, I could simply use the
pickle/unpickle functions to preprocess the tables.  I was originally
thinking that the pull flat data must have some similiarities to the
pickle function and wanted to see if it could be modified to also pass
up some sort of .ini representation before casting it to LV types. Since
I have your attention, do you think there is a possibility of embedding
the remote debugging message handler in the LuaVIEW core so that it
could always be available in any unmodified script thread?

- Mike

On 4/19/07, Andy Reding <ATReding at gwlisk.com> wrote:
> Mike,
>
>         I can't open the LV code (I'm still running older versions of
> LV) but I looked at the lua code, which is where the magic seems to be

> happening anyway. It looks like (correct me if I'm misunderstanding) 
> that the table is being pickled before it is sent, and being wrapped 
> in an unpickle() function. So when the message is sent, it is 
> essentially sent along with the command to unscramble it when it 
> arrives. Does that sound right?
>
>         If so, can you just use the same principle for your current 
> setup? Basically write a lua wrapper to pickle the table, then let 
> that function pass it to the global handler? Sounds like that would 
> accomplish the same thing.
>
>         What I thought you meant originally was that you wanted to 
> just access the unprocessed binary representation of the table inside 
> the lua state as a byte string - which wouldn't be possible because 
> there is no guarantee that lua stores the table contiguously. But if 
> by "pickled" you really mean this serialized text representation, it 
> would seem a lua-side preprocessing function would be simplest, then 
> just do a pull string on the LV side. Sorry I misunderstood your 
> original intention.
>
>         Andy
>
> P.S. That pickle/unpickle system is some pretty neat code. I might 
> have to steal that... Gotta love public domain code.
>
> -----Original Message-----
> From: luaview-users-bounces at lists.luaforge.net
> [mailto:luaview-users-bounces at lists.luaforge.net] On Behalf Of Mike 
> Sachs
> Sent: Tuesday, April 17, 2007 10:38 PM
> To: A forum for LabVIEW programmers that use LuaVIEW
> Subject: Re: [LuaVIEW-users] Modified 'pull flat data'
>
>
> Hi Andy,
>
> I understand that to translate (Marshall?) the lua table structure to 
> c/c++ would require type information, but all I want is to be able to 
> house the table state in a LabVIEW based global string mechanism and 
> then pass it to another LuaVIEW script thread which contains an 
> identical table.  I am attaching a remote debugger that I wrote some 
> time again that uses a pickling routine that is capable of recursively

> parsing a table and spitting it out as a string, so I know it can be 
> done.
>
> On 4/17/07, Andy Reding <ATReding at gwlisk.com> wrote:
> > Mike,
> >
> >         I don't know exactly how the luaview engine pulls its data, 
> > but I have used lua in C++ programs and I don't think it is possible

> > to exchange data without type information. Lua uses a virtual stack 
> > to
>
> > handle the data exchange between the virtual machine and the host 
> > program. In C/C++, everything is strictly typed so you must be able 
> > to
>
> > translate into a valid C data type to extract data, and you need to 
> > know the type when you pull it. I expect that the luaview pull 
> > function is parsing the type definition of the cluster to pull the 
> > data from the stack in some sort of recursive loop - which is why 
> > every element in the cluster needs to be named and needs a type that

> > translates directly into a C type. I think ultimately this is a 
> > limitation of lua, and the lua code itself would probably need to be

> > modified to change it. I'm sure the CIT guys will correct me if I'm 
> > wrong.
> >
> >         I know that in C/C++ it is possible to check the type of an 
> > element on the stack and then pull the correct type at runtime, but 
> > I don't think luaview supports such functionality. I've wanted to 
> > have the capability to check the type of a stack element before - 
> > perhaps that would be a simpler change to make to the core code? It 
> > would require us to do some parsing and run-time checking on the LV 
> > side before we pulled stack elements, but it might be possible.
> >
> >         Don't know if this helped or hindered...
> >
> >         Andy
> >
> > -----Original Message-----
> > From: luaview-users-bounces at lists.luaforge.net
> > [mailto:luaview-users-bounces at lists.luaforge.net] On Behalf Of Mike 
> > Sachs
> > Sent: Tuesday, April 17, 2007 12:34 PM
> > To: luaview-users at lists.luaforge.net
> > Subject: [LuaVIEW-users] Modified 'pull flat data'
> >
> >
> > I was wondering if it might be possible to create a modified version

> > of the pull/push flat data whose purpose is simply to obtain a 
> > 'pickled' string representation of a Lua table.  It seems that the 
> > original version of the pull flat data must be doing something like 
> > that already. My goal is to extend a global data manager that 
> > currently only works with numeric and boolean data types and is very

> > useful as a global data store between script threads or from a 
> > script thread to LabVIEW.
> >
> > Mike Sachs
> > Intelligent Systems
> >
> > _______________________________________________
> > LuaVIEW-users mailing list
> > LuaVIEW-users at lists.luaforge.net 
> > http://lists.luaforge.net/cgi-bin/mailman/listinfo/luaview-users
> >
> > _______________________________________________
> > LuaVIEW-users mailing list
> > LuaVIEW-users at lists.luaforge.net 
> > http://lists.luaforge.net/cgi-bin/mailman/listinfo/luaview-users
> >
>
> _______________________________________________
> LuaVIEW-users mailing list
> LuaVIEW-users at lists.luaforge.net 
> http://lists.luaforge.net/cgi-bin/mailman/listinfo/luaview-users
>

_______________________________________________
LuaVIEW-users mailing list
LuaVIEW-users at lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luaview-users



More information about the LuaVIEW-users mailing list