lua dictionary mechanism

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

lua dictionary mechanism

Dan Marks
Is it possible to use the lua dictionary mechanism to keep a data
space that is separate from the global variables in lua?  I would like
to create a separate variable namespace that is accessible from
several currently running lua threads.  To do this, I wanted to create
a new kind of lua_tag that would have the settable/gettable redefined
to retrieve the objects from this new table, so that many lua instances
could retrieve this data from the same namespace.

I was thinking of creating a separate lua interpreter instance that would
be for just storing global variables, and then I would just use a 
semaphore to block so that only one other thread could access it at once.
But then I have to duplicate the variable instance to prevent lua_Objects
from this instance to being passed back to other threads, which would
no longer synchronize on the semaphore used to prevent concurrent access.

Maybe this will just have to wait for a multithreaded lua. ?

Dan

Dan Marks
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lua dictionary mechanism

Carlos Augusto Teixeira Mendes
>I was thinking of creating a separate lua interpreter instance that would
>be for just storing global variables, and then I would just use a 
>semaphore to block so that only one other thread could access it at once.
>But then I have to duplicate the variable instance to prevent lua_Objects
>from this instance to being passed back to other threads, which would
>no longer synchronize on the semaphore used to prevent concurrent access.
>
>Maybe this will just have to wait for a multithreaded lua. ?
>

Hi,

I am currently working in a monitor construct that will be incorporated in
LuaMT (the multithreaded version of Lua).  I expect to release a version of
it soon.  It will be announced here in the list.

[]s,
Carlos Augusto.

Reply | Threaded
Open this post in threaded view
|

Small setback in porting Lua to Windows CE

Michael T. Richter
I got Lua 3.1 ported to Win32 with no difficulty.  Putting the engine 
into DLLs was also a trivial operation (the only source changes being 
required involving function exports).  At this stage I have Lua in a form 
perfect for embedding into Win32 applications with a very small overall 
footprint.

This is not the case for Windows CE, however.  There are a few too many 
assumptions built into Lua for it to be easily ported to that platform.  
The biggest assumption is that everyone will have access to FILE* 
operations (fopen, fclose, fprintf, etc.) on every platform.  This is sadly 
not the case.

Many of the things which use FILE* operations are trivially excised with 
conditional compilation and have adequate replacements which don't require 
FILE* functions.  For example I can always use Windows CE primitives to 
open a file and read it into a buffer and then execute the buffer.

Error reporting, however, is not so trivially patched up.  It makes heavy 
use of fprintf, and I have no access to that suite of functions in the 
Windows CE environment.

I'm going through and hacking in some replacements, even to the point of 
extending ZIO to allow Windows CE users to directly use files.  But it 
would be nice if future versions of Lua would use things like sprintf and a 
call to an easily overridden function for error reporting instead of 
using fprintf directly to minimize porting impact.
-- 
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

RE: lua dictionary mechanism

Samson
In reply to this post by Dan Marks
You want some sort of shared memory space, 

Under Win32 threads can have there own copys of global variables, called
thread local storage (TLS)
I think you could declare 
 extern lua_State *lua_state;
as TLS and have each thread running an independant lua VM, each with its own
variables.

You would have to 
 lua_setstate (lua_State *st);
to your shared state before any thread accessed the shared area, and this
make the threads own state inacessable, not very
useful...hmm

You will probably end up having to write some C extension functions, called
shared_var_get,shared_var_set which copy
variables between the shared state and the local state.

What would be nice ( on a low level ) is if we could map areas of the VM
address space so they were shared between states,
sort of like what MVS does.

As for UNIX...

lyndon

> -----Original Message-----
> From:	Dan Marks [SMTP:[hidden email]]
> Sent:	Wednesday, October 14, 1998 2:31 PM
> To:	Multiple recipients of list
> Subject:	lua dictionary mechanism
> 
> 
> Is it possible to use the lua dictionary mechanism to keep a data
> space that is separate from the global variables in lua?  I would like
> to create a separate variable namespace that is accessible from
> several currently running lua threads.  To do this, I wanted to create
> a new kind of lua_tag that would have the settable/gettable redefined
> to retrieve the objects from this new table, so that many lua instances
> could retrieve this data from the same namespace.
> 
> I was thinking of creating a separate lua interpreter instance that would
> be for just storing global variables, and then I would just use a 
> semaphore to block so that only one other thread could access it at once.
> But then I have to duplicate the variable instance to prevent lua_Objects
> from this instance to being passed back to other threads, which would
> no longer synchronize on the semaphore used to prevent concurrent access.
> 
> Maybe this will just have to wait for a multithreaded lua. ?
> 
> Dan
> 
> Dan Marks
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Roberto Ierusalimschy
In reply to this post by Michael T. Richter
> I'm going through and hacking in some replacements, even to the point of 
> extending ZIO to allow Windows CE users to directly use files.  But it
> would be nice if future versions of Lua would use things like sprintf and a
> call to an easily overridden function for error reporting instead of
> using fprintf directly to minimize porting impact.

We are working on that. All error output will be done through a single
function _ALERT; its build-in definition writes to stderr. Nobody else will
write to stderr in the interpreter. (Besides a few extra build-in
functions, such as "sort", we hope this is more or less all that will be
new in version 3.2.)

-- Roberto

PS: nevertheless, it is worth reminding that all this "FILE* functions" are
strictly ANSI, and should be supported by any compiler that claims to
understand ANSI C.

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Alan Watson-2
> PS: nevertheless, it is worth reminding that all this "FILE* functions" are=
> 
> strictly ANSI, and should be supported by any compiler that claims to
> understand ANSI C.

Only "conforming hosted implementations" are required to
provide the whole library. A "conforming freestanding
implementation" of ANSI/ISO C need only provide float.h,
limits.h, stdarg.h, stddef.h.

In a freestanding environment you can't even rely on the
string functions, let alone things like fopen and malloc.

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM

Reply | Threaded
Open this post in threaded view
|

Re: lua dictionary mechanism

Luiz Henrique de Figueiredo
In reply to this post by Dan Marks
>From: Dan Marks <[hidden email]>
>
>Is it possible to use the lua dictionary mechanism to keep a data
>space that is separate from the global variables in lua?  I would like
>to create a separate variable namespace that is accessible from
>several currently running lua threads.  To do this, I wanted to create
>a new kind of lua_tag that would have the settable/gettable redefined
>to retrieve the objects from this new table, so that many lua instances
>could retrieve this data from the same namespace.

sure, but it will be cleaner if you use set/getlobal to redirect "global"
variable access to tables.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Michael T. Richter
In reply to this post by Roberto Ierusalimschy
> PS: nevertheless, it is worth reminding that all this "FILE* functions"
> are strictly ANSI, and should be supported by any compiler that claims
> to understand ANSI C.

True, but not helpful.  When you're in a memory-restricted environment 
(I've got 16MB which is simultaneously my storage space and my execution 
space; the more data I have stored, the less room I have to execute 
programs), the decision to drop superfluous APIs is a rational one.

What would you be saying to someone who wants to embed Lua into some kind 
of controller?  Would you be as calmly dismissive?  Or do you reserve this 
kind of dismissal for the Windows-related platforms?
-- 
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

toLua: problem with nested classes

Cameron Tofer
In reply to this post by Samson
I am having trouble using nested classes with toLua. For example:

class Test1
{
    Test1();
    int x;
    int y;
    int z;
};

class Test2
{
    Test2();
    int a;
    int b;
    Test2    c;
};



at the lua prompt:
myclass = Test2:new();

--this line does not work
myclass.c.x = 5;


--i can get around it by
temp = myclass.c;
temp.x=5;


Is this a problem with toLua, or me.  It would be very helpful if this worked.

Thank you,

Cameron Tofer

Reply | Threaded
Open this post in threaded view
|

Re: toLua: problem with nested classes

pachydr
>class Test1
>{
>    Test1();
>    int x;
>    int y;
>    int z;
>};
>
>class Test2
>{
>    Test2();
>    int a;
>    int b;
>    Test2    c;
>};
>
>
>
>at the lua prompt:
>myclass = Test2:new();
>
>--this line does not work
>myclass.c.x = 5;
>
>
>--i can get around it by
>temp = myclass.c;
>temp.x=5;
>
>
>Is this a problem with toLua, or me.  It would be very helpful if this
worked.


look again; "c" is of type Test2, not Test1 -- there is no "x". :)

jdm







Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Roberto Ierusalimschy
In reply to this post by Michael T. Richter
> What would you be saying to someone who wants to embed Lua into some kind
> of controller?  Would you be as calmly dismissive?  Or do you reserve this
> kind of dismissal for the Windows-related platforms?

Please don't get me wrong. Even if I tried, my English is not good enough
for me to be "calmly dismissive" in a written message. I was not saying we 
don't care; quite the opposite. It is because we do care that we are
changing error messages to make it easier to use Lua in Windows-related
platforms (and other "non conforming" platforms). The point I was trying to
make (not even in the message, that was only a PS!) was: it is impossible
to make a software to run just "everywhere". So we use "conforming hosted
implementations" as our portability base. If we can make it more portable
than that, very good. But we cannot assume we will try to solve all
portability problems that may appear when porting Lua to "non conforming
hosted implementations" (for instance, we do not intend [at least for now] 
to get rid of the string library).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Michael T. Richter
> Please don't get me wrong. Even if I tried, my English is not good
> enough for me to be "calmly dismissive" in a written message. I was not
> saying we don't care; quite the opposite. It is because we do care that
> we are changing error messages to make it easier to use Lua in
> Windows-related platforms (and other "non conforming" platforms). The
> point I was trying to make (not even in the message, that was only a PS!)
> was: it is impossible to make a software to run just "everywhere". So we
> use "conforming hosted implementations" as our portability base. If we
> can make it more portable than that, very good. But we cannot assume we
> will try to solve all portability problems that may appear when porting
> Lua to "non conforming hosted implementations" (for instance, we do not
> intend [at least for now] to get rid of the string library). 

Sorry.  I got snippy for no reason.  I have a lot of UNIX-infested 
colleagues who will go out of their way to make life difficult for Windows 
developers and your message coincided with another bout of "let's make life 
hell on Windows developers" in the company.

I appreciate your help and the effort you've put in so far.  (And would you 
be interested in the source changes I've made so far which allow Lua to be 
done as a dynamic link library under Win32?)

-- 
Michael T. Richter    <[hidden email]>    http://www.igs.net/~mtr/
          PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Lyn A Headley-2
In reply to this post by Roberto Ierusalimschy
I just wanted to let you know that I didn't think you were calmly
dismissive at all.  That guy is way too uptight.

keep up the good work,
Lyn

Reply | Threaded
Open this post in threaded view
|

Re: toLua: problem with nested classes

Cameron Tofer
In reply to this post by pachydr

[hidden email] wrote:

> >class Test1
> >{
> >    Test1();
> >    int x;
> >    int y;
> >    int z;
> >};
> >
> >class Test2
> >{
> >    Test2();
> >    int a;
> >    int b;
> >    Test2    c;
> >};
> >
> >
> >
> >at the lua prompt:
> >myclass = Test2:new();
> >
> >--this line does not work
> >myclass.c.x = 5;
> >
> >
> >--i can get around it by
> >temp = myclass.c;
> >temp.x=5;
> >
> >
> >Is this a problem with toLua, or me.  It would be very helpful if this
> worked.
>
> look again; "c" is of type Test2, not Test1 -- there is no "x". :)
>
> jdm

oops, i screwed up it should be:class Test2
{
    Test2();
    int a;
    int b;
    Test1    c;
};

this is not my exact code, but it illustrates the problem, it would take
too long show my actual code.

cameron tofer


Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Bennett Todd-2
In reply to this post by Michael T. Richter
1998-10-16-17:49:42 Michael T. Richter:
> I have a lot of UNIX-infested colleagues who will go out of their way to
> make life difficult for Windows developers and your message coincided with
> another bout of "let's make life hell on Windows developers" in the company.

Speaking as a viciously Unix-infested person, I don't have much sympathy for
that kind of attitude. Everybody makes choices in their lives. I've made a
very deliberate choice to have absolutely nothing to do with Windows; I
believe that this is a professionally responsible choice for me to make, and
has left me much better off. Other people feel differently; let them live with
their choices.

I'd suggest to your Unix-infested colleagues that Windows is its own
punishment, there's no excuse for trying to make Windows' peoples' lives
harder, and even if they wanted to they don't stand a chance of competing with
Microsoft.

-Bennett

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Lyn A Headley-2
>>>>> "Bennett" == Bennett Todd <[hidden email]> writes:

    Bennett> Speaking as a viciously Unix-infested person, I don't
    Bennett> have much sympathy for that kind of attitude. Everybody

ok, let's just stop this right now.  this mailing list is for
discussing THE LUA EXTENSION LANGUAGE.

I hope this thread is now over.

-Lyn

Reply | Threaded
Open this post in threaded view
|

RE: Small setback in porting Lua to Windows CE

Adam Alpern
In reply to this post by Michael T. Richter
It's all a matter of opinion and personal experience. At my job I write
software that runs on Windows NT, Solaris, AIX, and HP/UX (2 flavors of
each UNIX, no less). I've found that most of my pain comes on the UNIX
end of things, especially when you throw signals, threads, and C++ all
together. Others have had different experiences.

Lua's one of the most portable programming language implementations I've
seen in quite some time. Your milage may vary.

-Adam

> -----Original Message-----
> From:	Bennett Todd [SMTP:[hidden email]]
> Sent:	Friday, October 16, 1998 1:39 PM
> To:	Multiple recipients of list
> Subject:	Re: Small setback in porting Lua to Windows CE
> 
> I'd suggest to your Unix-infested colleagues that Windows is its own
> punishment, there's no excuse for trying to make Windows' peoples'
> lives
> harder, and even if they wanted to they don't stand a chance of
> competing with
> Microsoft.
> 
> -Bennett

Reply | Threaded
Open this post in threaded view
|

Re: Small setback in porting Lua to Windows CE

Alan Watson-2
In reply to this post by Roberto Ierusalimschy
Back in the mists of time, Roberto wrote:

> We are working on that. All error output will be done through a single 
> function _ALERT; its build-in definition writes to stderr. 

I request that this function take (at least) three
parameters: the file name, line number, and error message.
Possibly syntax errors should have the last token read as a
fourth parameter. That will allow the format of error
messages to be changed to suit the user (e.g., I prefer
"file:line: message" to the more verbose format used
currently).

It might be nice to have a table containing a stack trace as
a further argument to this function.

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM