[LuaVIEW-users] Modified 'pull flat data'

Mike Sachs mike.sachs at gmail.com
Thu Apr 19 11:37:31 BRT 2007


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
>



More information about the LuaVIEW-users mailing list